Do you need both server-side tracking and a CDP?

The short answer

Server-side tracking and a customer data platform solve different parts of the data problem. Server-side tracking controls how selected web or app events move from the organisation to analytics and advertising destinations. A CDP creates and maintains the customer layer used to decide who should enter, leave or shape an audience.

One can exist without the other. The stronger design connects them only where a server-side signal improves a defined customer decision.

What server-side tracking does

A server-side setup receives approved events in an environment controlled by the organisation, applies agreed transformations or restrictions, then forwards permitted data to destinations such as analytics and advertising platforms.

It can improve governance, resilience and control over what is sent. It does not automatically resolve customer identity, reconcile CRM states or maintain reusable audiences across platforms.

What a customer data platform does

A CDP connects relevant customer sources, creates persistent unified customer records, resolves identity, applies lifecycle and audience rules, and keeps those audiences current across approved destinations.

Fractyl combines CRM, Google BigQuery, log-level GA4 data, relevant server-side signals and agreed operational sources. It then synchronises governed audiences to Google Ads, Meta, TikTok, DV360 and supported third-party data clean rooms.

How the two layers work together

• A person takes an approved action on the website or app.
• The server-side measurement layer processes the permitted event and identifiers under the agreed consent state.
• Relevant event data reaches GA4, BigQuery or another approved source environment.
• Fractyl connects the signal with maintained CRM, lifecycle and operational data.
• Identity and source-precedence rules update the persistent customer record.
• Audience rules decide whether the person enters, remains in or leaves a segment.
• The saved audience synchronises to its approved destinations on the required schedule, including up to hourly.

The customer state matters more than the event alone

A page view, form submission or purchase event describes something that happened. It may not reveal whether the person is a qualified lead, current customer, lapsed student, active member or otherwise ineligible for acquisition.

The CDP adds maintained customer context. That allows the same digital action to produce a different audience decision according to the person’s current relationship with the organisation.

Useful server-side signals are selective

• High-intent actions that help distinguish casual interest from a meaningful prospect.
• Confirmed conversions that should change suppression or lifecycle state quickly.
• Product, course, service or location interest that supports an approved audience rule.
• Consent and preference states required to govern downstream use.
• Campaign and source context needed to evaluate lead or customer quality.
• Outcome events that can connect media activity with qualified conversion or customer value.

Do not send every event into the customer layer

More event volume does not automatically produce a better customer record. High-frequency, low-value events can increase processing, quality and governance burden without changing an audience decision.

Start with the minimum signals needed to prove eligibility, exclusion, lifecycle change or commercial outcome. Add another event only when the decision and measurement design require it.

Server-side does not mean consent-free

Moving collection to a server does not remove privacy, notice, consent or purpose obligations. It also does not make every available identifier appropriate for matching or activation.

The client remains responsible for lawful collection, consent where required, accurate source data and approved use. The implementation should pass the current consent state, minimise fields and document which destinations receive each signal.

Identity and hashing have separate jobs

Identity resolution determines whether records from different sources belong to the same person. Hashing transforms an identifier into a consistent non-plain-text value for governed matching or activation.

Hashing does not resolve duplicate records, decide which source wins, create permission or make uncertain matches reliable. Those rules belong in the customer-data design before the audience is activated.

Measure the business decision, not just data delivery

• Confirm the event arrives with the expected consent and field controls.
• Check the persistent customer record updates for the right person and reason.
• Track audience entry and exit, source audience size and destination match rate.
• For suppression, measure eligible acquisition exposure removed and mistaken exclusions.
• For lead or value signals, compare qualified conversion and downstream customer value.
• Use an agreed baseline, test or holdout when the commercial decision warrants it.

A sensible first implementation

Choose one customer decision, one or two server-side signals, the CRM or operational field that confirms the outcome, and the destinations where the audience will be used. Define the owner, consent behaviour, refresh cadence and measurement plan before connecting more data.

Fractyl can operate that customer layer as a managed capability, be licensed to an agency or client team, or work through a shared model. The server-side measurement setup can remain with the existing data, analytics or agency partner.

Current capability and roadmap remain separate

Fractyl currently connects relevant server-side and analytics signals with persistent customer records and governed paid-media audiences. Live destinations include Google Ads, Meta, TikTok, DV360 and supported third-party data clean rooms.

Media mix modelling is in beta. AI-assisted segments and attribution feedback are roadmap direction, not current live capability. The data foundation can prepare for those uses without presenting them as available today.