Implement first-party data consent in server-side delivery

First-party data consent is an implementation concern when website choices and server delivery happen in different systems. A queue needs an explicit way to determine which data may leave for which destination. Moving the request from a browser to a server does not establish permission to send it.

This guide covers technical checks. The permitted uses, regions and retention rules must come from your organization's approved policy and applicable platform requirements. A successful API request is not a finding of legal compliance.

Separate data origin from the sending decision

Data collected through your own form or checkout has an identifiable source. Preserve that source alongside the relevant choices and the version of the rules used to interpret them. Do not infer permission merely because the record is in your database.

A conversions API payload should follow the approved mapping for the destination and intended use. A hash changes a value's representation; it does not resolve an unknown permission state. Preparation of supported identifiers is covered separately in hashing and normalization.

Define how your integration represents granted, denied and unresolved choices. Missing data should not silently become granted. Specify who owns the policy decision so developers do not fill gaps with a default that happens to let a request through.

Configure Google's defaults and updates in order

Google's website consent-mode guide describes a default state followed by updates. For a gtag.js implementation, the default command belongs before commands that send measurement data, such as config and event. The guide's supported signals include ad_storage, analytics_storage, ad_user_data and ad_personalization.

For an asynchronous consent tool, wait_for_update sets a wait in milliseconds. The guide's example uses 500 milliseconds. It is a timing setting, not a consent lifetime and not proof that the user agreed.

Consent mode does not itself save the user's choice. Your consent solution must persist it and apply the appropriate update on later pages. The guide also describes changing a previously granted state to denied. Test that path as well as first-time acceptance.

Google Tag Manager has its own consent APIs, including setDefaultConsentState and updateConsentState. Follow the implementation method you actually use; do not paste browser commands into an unrelated server payload and assume the semantics carry over.

Carry enough context into the queue

A useful queue record can reference the event, source, decision time, relevant choices and policy version without duplicating unnecessary personal data. This is a design recommendation for auditability, not a shared platform schema.

A historical snapshot alone cannot settle how a later withdrawal affects a queued record. Define that behavior explicitly. Keep event identity stable through the queue; the retry and idempotency guide covers repeated delivery.

Map each destination separately

Check the exact contract of the receiving workflow. A flag named for restricted data processing, an opt-out field and a tag consent state can have different meanings. Do not substitute one for another based on similar names.

Meta's API guide requires an accurate action_source. That field identifies where the action happened; it is not a consent declaration. A website event should not acquire a different source just because a server forwards it.

For TikTok, verify the current event schema and the applicable privacy-control documentation before assigning a field or declaring its effect. This guide supplies no TikTok consent payload or eligibility rule. Leave an unverified mapping unresolved rather than copying Google's settings into it.

The same source discipline applies to other context. See client IP and user agent in server events for the separate question of where those values originate.

Test choices against actual outgoing data

Use controlled cases for no choice, acceptance, refusal, a changed choice and a delayed retry. For each, record the expected treatment before running the test. Inspect whether a request was sent and which fields it contained. Check downstream queues as well as the first receiving service.

An HTTP success response does not test the accuracy of your consent mapping. Equally, an API rejection does not prove the implementation respected the visitor's choice. Compare the result with the approved rule and identify the exact stage that diverged.

Keep logs sufficient to explain the decision without treating logging as permission to retain every identifier indefinitely. Access and retention should follow the same approved policy. A useful audit result names a reproducible mismatch, such as an unresolved choice becoming granted during retry, and the component that must be corrected.

Sources