Technical and private review

Technical consent and server-side review

Six decisions that test whether a preference is enforced consistently from collection through to every destination.

It starts from categories and decisions already defined by the client. Choose the closest description of their technical implementation.

The review runs entirely in this browser. It does not send, store, or share your answers.

Every decision, and what to do with each answer

Why it matters: A technical decision cannot be enforced consistently when tags, purposes, and destinations do not share a current inventory.

The inventory depends on an automated scan or on what each team declares.

Next check: Trace one page and one critical flow and compare network calls, tag manager, CMP, and documentation.
An inventory exists, but owners, purposes, or destinations become outdated.

Next check: Assign an owner and review date to every technology before changing categories or blocking rules.
Technologies, purposes, data, owners, and destinations form one shared inventory.

Next check: Check that additions, changes, and removals update the inventory within the same release flow.
The inventory is reconciled with real traffic and blocks releases without classification.

Next check: Maintain periodic reconciliation and record exceptions with an owner and expiry date.

Why it matters: If each system translates the preference independently, the same person can receive incompatible treatment within one journey.

Each tool interprets categories or signals according to its own configuration.

Next check: Compare the possible states in the CMP, browser, tag manager, CDP, and two relevant destinations.
A shared model exists, but some integrations retain their own translations or values.

Next check: Document active translations and remove any without an owner or current use case.
States, versions, and propagation rules are documented for every consumer.

Next check: Test preference changes and confirm which systems receive the new state and with what latency.
Propagation is observed, tested, and reconciled between source and consumers.

Next check: Maintain transition tests and alerts for unknown, stale, or contradictory states.

Why it matters: A correct banner does not prevent early collection, pending queues, or identifiers created before the preference is enforced.

The banner loads first and tags are expected to wait for its signal.

Next check: Capture a new visit with a clean network state and verify which requests and identifiers appear before a decision.
Primary tags respect the state, but queues, SDKs, or exceptions are not tested in the same way.

Next check: Inventory deferred loads, queues, and SDKs and test acceptance, rejection, withdrawal, and partial change.
Collection has defaults, blocking, and transitions defined by purpose.

Next check: Automate critical cases and confirm that withdrawal stops future collection according to the agreed design.
States are tested on every release and leave reviewable evidence.

Next check: Add negative and race-condition tests to detect loads that occur before the decision is received.

Why it matters: Moving delivery server-side increases control, but can also centralize data and replicate it to more destinations than necessary.

The server-side layer forwards the received payload and each destination ignores what it does not use.

Next check: Compare the inbound payload with two outbound payloads and flag fields with no declared technical purpose.
Destination filters exist, but depend on manual and poorly visible configuration.

Next check: Version filters and add a test that fails when unauthorized fields appear in an outbound payload.
Each destination receives an explicit list of fields, conditions, and transformations.

Next check: Check that new fields are not propagated by default and are approved within the change flow.
Minimization is contract-tested and observed in real traffic.

Next check: Maintain reconciliation across contracts, deployed configuration, and production traffic samples.

Why it matters: Propagating a signal does not prove that the destination interprets it, updates state, or stops the expected processing.

The flow is considered correct when the connector accepts the request without error.

Next check: Choose one destination and verify the request, response, and final state visible in the platform.
Primary destinations are tested manually, without shared evidence or a defined frequency.

Next check: Define one reproducible case per destination with input, expected output, and a review owner.
Each destination has documented acceptance, rejection, withdrawal, and update cases.

Next check: Run the cases after changes to the CMP, connectors, APIs, or consent model.
Enforcement is reconciled and deviations create a traceable incident.

Next check: Review coverage, detection times, and destinations without a verifiable final signal.

Why it matters: Configuration without owners, records, and a change procedure cannot be maintained as platforms and purposes evolve.

Incidents depend on whoever configured the original CMP or connector.

Next check: Take one recent incident and test whether another person can reconstruct the affected state, version, and destination.
Documentation and logs exist, but there is no clear owner for every stage of the flow.

Next check: Assign ownership across inventory, CMP, collection, server-side layer, and critical destinations.
Changes, tests, owners, and failure response form part of operations.

Next check: Test the procedure with a real change and correct any step that depends on implicit knowledge.
The team can detect, contain, and explain a deviation without depending on one person.

Next check: Maintain drills, debt reviews, and owner rotation to preserve that capability.

Reading of your answers