Hey everyone! 👋 I've been lurking here for a while, picking up some fantastic tips on security integrations, but this is my first time posting. I come at this from a slightly different angle—my world is marketing ops and lead flows—but our recent security stack overhaul meant I got pulled into the Zscaler Proof of Concept to understand impacts on our web analytics, tracking, and campaign attribution. It was... enlightening.
We just wrapped up a pretty extensive three-month PoC, and while the sales engineers were fantastic and the platform is undoubtedly powerful, I couldn't help but notice a pattern. There were certain metrics and tests our team wanted to run that kept getting gently steered away from or glossed over. I'm sharing because I think these are crucial for any ops-minded person (marketing, sales ops, IT ops) to consider before signing.
Here are the three things they really didn't want us to measure in detail:
**1. The True Impact on End-User Experience for External-Facing Applications**
This was a big one for us. We run a ton of personalized web sessions, demo environments, and tracking for inbound leads. Zscaler was super focused on internal user experience to SaaS apps (which was great), but every time we asked about quantifying latency or potential session drops for *our own customers* hitting our applications through their ZIA cloud, the conversation got vague. They provided high-level SLAs but discouraged us from setting up controlled A/B tests comparing direct access vs. Zscaler-routed traffic for key conversion paths (like form fills or demo sign-ups). For a marketing team living and dying by conversion rates, this was a red flag. We did some unofficial tests and saw a slight but noticeable lag in certain geographic regions.
**2. The Full Administrative Overhead for Dynamic Policy Changes**
They showcased the policy manager beautifully, but always with pre-baked, simple rules. We wanted to measure the *time* it would take for our teams to implement and test a net-new policy in a real-world scenario—like isolating a new threat feed for our marketing cloud instances or creating an exception for a specific partner integration. We asked if we could log hours during the PoC for a few mock requests. They preferred to do it for us, which felt like we weren't getting the true picture of the learning curve and ongoing ops burden. In marketing ops, if I can't quickly spin up a safe path for a new tracking domain, it blocks campaigns.
**3. The Actual "Time to Insulate" a New Cloud Service**
This is huge in today's environment. We're constantly adopting new tools (think a new webinar platform, a CDP, a social scheduling tool). Their literature talks about instantly securing new SaaS apps. What we wanted to measure was the full cycle: from IT ticket submission, through discovery, policy creation, testing, and rollout for a *deliberately unknown* test app we'd add during the PoC. They pushed back, saying the PoC environment wasn't set up for that. Instead, they demoed adding a known, pre-vetted service. The distinction is critical—the real-world overhead isn't in adding Salesforce, it's in quickly and safely enabling that niche, startup-powered tool the growth team just signed up for.
Has anyone else run into similar roadblocks during their evaluations? I'd love to hear how you navigated these conversations or what you ultimately decided. We're still in the decision phase, and weighing these operational nuances against the security benefits is tough.
Automate everything
You've hit on the absolute core issue with any proxy-based architecture. They always focus on the internal user experience because that's their comfort zone and primary use case. The external experience for your web apps, especially anything with real-time sessions or personalization, becomes a secondary concern.
When you're terminating traffic in their cloud, you're adding a hop. That introduces latency jitter, which they can easily average out to look good on a dashboard. But for your demo environments and lead tracking, those brief spikes in latency are where sessions drop and attribution breaks. They can't control the last-mile internet path from their data center to your customer, so they avoid promising specific numbers there.
You need to demand to see the 95th or 99th percentile latency figures for traffic egressing from their POPs to your application's hosting region, not just averages. If they're hesitant, that's your answer.
Been there, migrated that
Of course they focused on internal. That's the easy win. The external-facing app impact is the whole ballgame for anyone with a public website. Did you get them to commit to a baseline performance SLA for your specific geo-regions? Or was it all hand-wavy "internet weather" excuses?
screenshots or GTFO
Exactly. They had lots of "typical performance" charts but wouldn't commit to a baseline for our Asia-Pacific users. Every time we asked, it was indeed that "internet weather" line.
So how do you actually push for a real SLA in a PoC? Do you set up your own monitoring from those regions to test against their claims? I'm new to this and that part feels tricky.
You're absolutely right about demanding the 95th/99th percentile latency. That's the only metric that matters for real user experience, not smoothed averages. The jitter is what kills stateful connections.
A practical test I run is to set up a simple endpoint in my app's actual hosting environment, say us-east-1, that echoes back the request timestamp and the POP it came from. Then I fire sustained traffic from a synthetic monitoring tool from the regions they claim to serve. You'll see the latency distribution plainly, and you'll identify which specific Zscaler POPs are problematic. They can't argue with your own data.
Their reluctance to commit often stems from the fact that their egress path is just commodity internet. They have no SLA with the upstream providers from their POP to your AWS VPC or GCP VPC, so they can't offer one to you. That's the architectural reality they're avoiding.
Boring is beautiful
Spot on about demanding high percentile latency figures. Averages are useless for this.
That last mile from their POP is the weakest link, and it's often where they've leased transit from the cheapest provider. You can get them on this by asking for their peering agreements at each POP. If they're heavily reliant on a single tier 2 provider for egress in a region, you'll see the jitter and packet loss spike during peak hours.
Push them to show you the traffic path from their POP to your actual cloud VPC or data center IPs during the PoC. Not a generic test to AWS us-east-1, but to your specific endpoints. The difference can be shocking.
VendorNegotiator
Right, peering agreements are the key ask. Even if they show them, you need to read between the lines.
A list of peers doesn't tell you about the traffic ratios. They might peer with a major cloud provider at a major IX, but if 90% of their egress traffic is routed over a cheap transit link because it's less congested, your performance still suffers. Ask for their traffic engineering policy for your target geos during the contract negotiation.
The other item they'll dodge is committed versus best-effort capacity on those peer links. That's what causes the peak-hour spikes.
Your CFO thanks me.