Web Analytics · Server-Side & First-Party
First-Party Tracking Architecture
Which signals move first-party is an architecture decision, argued signal by signal before anything is provisioned.
Moving server-side involves several decisions: which signals pass through your domain, how long you retain them, and which parts still depend on third-party mechanisms. We resolve those choices before the infrastructure is built.
A clear architecture decision that explains what should move first-party, what should not, and why.
Some of the 500+ brands we've worked with
See all references
How we run it
From signal inventory to a dated architecture recommendation
We test the proposed architecture against browser limits, vendor constraints, consent requirements, and the cost of operating it. Four steps lead to a buildable decision before infrastructure spending begins.
How we hold ourselves to it
- Which signals actually need a first-party endpoint — We identify the signals that genuinely benefit from a first-party endpoint and leave the others alone, avoiding infrastructure that solves no meaningful problem.
- CNAME, a full container, or a hybrid? — ITP caps a CNAME-based cookie when it detects cloaking. A full server container avoids that particular ceiling but costs more to operate, so we assess the tradeoff against your traffic and budget.
- Retention and consent, defined before launch — Before implementation, we specify how long first-party data is retained and how each consent choice propagates to downstream destinations.
- What stays third-party, documented honestly — Some signals still depend on a cross-site mechanism such as the Storage Access API rather than a durable first-party cookie. We document those dependencies instead of promising a fully first-party setup that is not realistic.
Inventory current signals
We list what you collect today, where it goes, and which parts already touch third-party domains or storage.
Signal inventory
- AI assist
- Clusters your current tags by where data goes.
- Human gate
- You confirm the current tag inventory is accurate.
- Owners
- Measurement Architect, Ad Platform Owner
Evaluate the options
We compare realistic approaches against your traffic volume, operating capacity, and budget.
Options comparison
- AI assist
- Scores each approach against your traffic and budget.
- Human gate
- You pick which tradeoffs you're willing to accept.
- Owners
- Measurement Architect, Ad Platform Owner
Design the target architecture
We specify which signals move where, what data retention applies, and how consent propagates end to end.
Architecture blueprint
- AI assist
- Drafts retention rules from your approved consent policy.
- Human gate
- Your privacy owner approves the retention and consent rules.
- Owners
- Measurement Architect, Privacy Stakeholder
Hand off for implementation
We package the design as a clear, testable specification for your team or ours to implement.
Implementation brief
- AI assist
- Packages the blueprint into a testable implementation spec.
- Human gate
- Engineering lead confirms the spec is buildable.
- Owners
- Measurement Architect, Engineering Lead
Start with what survives ITP's cookie limits
Automation clusters the current tags by destination, scores each option against your traffic and budget, drafts retention rules from the approved consent policy, and packages the result into a testable spec. The decisions are yours and your reviewers': which tradeoffs are acceptable, what the retention and consent rules will be, and whether the spec can actually be built.
What you get
A recommendation with a clear browser-policy review date
The deliverables explain the decision, its tradeoffs, and what the implementation team needs next.
Architecture document
Architecture blueprint
What moves first-party, what doesn't, and the retention and consent rules governing each signal.
Accepted when
Every signal in the inventory is placed as first-party, unchanged, or dropped, each with a reason.
Cadence: Revisited when signals change
Decision memo
Options comparison
The approaches we considered, their tradeoffs, and why we recommend the one we do.
Accepted when
Each rejected option states the specific constraint that rejected it.
Cadence: Once, before the build commits
Technical brief
Implementation brief
A spec ready to hand to whoever builds the infrastructure next.
Accepted when
The build team can start from the brief without a second discovery round.
Cadence: Handed to the build team once
We call it done when: the recommended architecture has been checked against the platforms you actually use, its operating cost is estimated, and an engineering lead calls the spec buildable.
Fit and readiness
Server-side tracking is a deliberate architectural choice rather than a default setting
This work fits teams that need to choose an approach before committing to infrastructure.
A good fit when
- Server-side tracking carries a real operating cost, but nobody can yet show which first-party signals would justify it in your setup.
- Your tools need one retention and routing strategy, yet the team cannot commit to infrastructure until those rules are agreed.
- You're comparing CNAME cloaking, a full server container, or a hybrid and need the tradeoffs documented.
Better handled as other work when
- You already know you need a server container and just want it built. That is Server-Side GTM & Cloud Setup.
- Your collection route is settled, and the remaining work is transforming data downstream in the warehouse. That belongs in Data Enrichment & Transformation.
If one of these is closer to your situation, start here instead: All Server-Side Tracking & First-Party Measurement tasks
We call it done when: the current tag inventory is confirmed accurate and you have named which tradeoffs you are willing to accept.
People who build your measurement system
Zeo designs measurement systems that connect a business decision to governed collection and reporting you can check. The people shown here work on the part of that system this page covers.
Zafer Yıldız
Web Analytics Manager
Abdullah Tanıdır
Performance Marketing Team Lead
Sevda Yurtvermez
Performance Marketing Team Lead
Serap Yurtvermez
Performance Marketing Team Lead
İlker Emir
Senior Performance Marketing Executive
Mirzamin Aghazada
UI/UX Designer
İpek Ezer
Performance Marketing Executive
Deniz Çağın Demirci
Frontend Developer
Burak Pehlivan
Co-founder & CEO
Didem Himmetli
Marketing Executive
Onur Durdağı
Performance Marketing Executive
Tools we use
Tools behind this work
Notionholds the signal inventory and the dated recommendation the whole engagement builds toward
Stapethe reference server-container option this page's target-architecture step evaluates against the alternatives
Google Tag Managerthe server-container variant the target architecture specifies, not the standard web container
Where this fits
Keep going
Same capability
Server-Side GTM & Cloud Setup
The implementation brief stops at a buildable spec; this is where the cloud project, the subdomain, and the routing actually get provisioned against it.
Same capability
Consent Mode v2 & CMP Integration
The blueprint fixes retention and consent propagation per signal; whether each rule survives contact with real storage and outgoing requests is tested under accept, reject, and withdrawal.
Same capability
Server-Side Monitoring & Reliability
A dated recommendation ages between browser releases; destination-level alerts are how you find out a signal stopped arriving rather than waiting for the recheck.
Next step
Decide which signals truly need to move first-party
Before we start
Questions teams ask before booking
Not necessarily. Some setups get most of the benefit from a simpler CNAME-based approach. We tell you honestly which one fits, even if it's not the more elaborate option.