Dynamic Number Insertion has been the backbone of call attribution since 2012. The mechanism is elegant: a visitor arrives, JavaScript swaps the static phone number on the page for a session-specific tracking number, and the call platform maps that number back to the session, campaign, keyword, and ad group. The problem: every layer of that mechanism depends on browser behavior that's actively being constrained, and the deprecations aren't done.
What's actually breaking and why
Three separate browser-level changes are fragmenting traditional DNI simultaneously:
Four architectures for privacy-resilient DNI
None of these are perfect in isolation. The right stack for most teams is 2 and 3 combined, with 4 as a fallback for enterprise deployments that need 100% attribution fidelity.
| Architecture | ITP resilient | Cross-device | Complexity | Coverage |
|---|---|---|---|---|
| JS cookies only | No | No | Low | ~55% of sessions |
| Server-set first-party cookies | Yes (no 7-day cap) | No | Medium | ~75% of sessions |
| UTM persistence + server-side session | Yes | Partial | Medium | ~82% of sessions |
| Hashed identity (email/phone) | Yes | Yes | High | ~92% of sessions |
Server-side DNI: the future-proof architecture
The shift that solves the ITP problem is moving session initialization server-side. Instead of relying on a JavaScript cookie to persist the session, you set the tracking cookie from your server on the first request. Safari's ITP cap applies only to cookies set by JavaScript — server-set cookies with an explicit expiry are treated differently and aren't subject to the 7-day cap.
The implementation: when a user arrives from a paid channel, your edge function or server captures the UTM parameters, generates a session token, stores the attribution data server-side, and sets an HttpOnly cookie with the session token. DNI then reads this server-generated session to assign the tracking number, rather than relying on a JS-written cookie. The call platform maps the number to the server-side session, which has the full attribution chain.
This architecture is also GDPR/CCPA compliant by design: you're not writing anything to the browser beyond an opaque session token, and all attribution data lives in your own infrastructure.
Implementation checklist
- Audit your current DNI implementation: what type of cookie is it setting, and what's the effective session expiry on Safari?
- Instrument your attribution gaps: segment "last-touch call attribution" by browser/OS to see where Safari and Firefox are showing as direct/unknown.
- Move session initialization server-side and store UTM data at the origin, not in the browser.
- Set up UTM pass-through in your call tracking platform so server-generated sessions can be reconciled with ad-platform click data.
- Implement GCLID/FBCLID server-side storage — these expire faster than most attribution windows if stored client-side only.
- Test your attribution coverage by vertical before and after migration. Expect to recover 15–25% of previously dark sessions within 30 days.
Ready to close the loop on your
revenue stack?
Teldrip Pulse handles call tracking, RTB and attribution. Signal handles telephony, AI voice agents and outbound. Spin up a free trial in minutes.
7-day free trial on Signal · Cancel any time