A guide to advertising identity.

An identifier is a reference within a system

An identifier is a value used to distinguish an entity or record within a defined scope. Customer 428 in a retailer’s database is meaningful because the retailer has a record behind it. Another retailer can use 428 for somebody else. The value, the system that issued it and the thing it refers to belong together.

Recognition does not require a name. A site can recognise the same available browser key on two visits while knowing nothing about the visitor’s civil identity. Conversely, a business may know a customer’s name and still be unable to recognise their next advertising opportunity. Knowing, recognising and being able to reach someone are separate capabilities.

People, accounts and contact points overlap

A person can have several accounts and several email addresses. A couple can share a shopping account, a household inbox or a streaming subscription. An email address is a contact point; a customer number is a business record; a profile is a subdivision chosen by a service. None automatically establishes one human.

Authentication checks a claim through credentials or another authenticator. Identity proofing asks who the claimant is; authorisation determines what they can access. An authenticated streaming account still leaves open who is holding the remote. The strength of the login and the identity of the audience are different questions.

• NIST: authentication and authenticator management

A device contains several identity contexts

A laptop can contain several browser profiles. A phone contains apps, webviews and standalone browsers. Each can maintain its own state. A browser identifier generally recognises a particular stored browser context, while an app identifier may recognise an installation. These records may belong to one person, several people or an automated process.

Household identity adds another layer. An account or delivery address may support a household relationship. A shared internet connection may provide evidence for an inference. Neither establishes who saw a particular advertisement. A household is a useful buying unit, but it is not a person with a larger screen.

Events and advertising objects have identities too

A session groups activity under the service’s session rules. An event ID distinguishes an occurrence or helps deduplicate reports of it. An order ID refers to a transaction. A campaign, creative, placement, publisher or deal ID identifies an advertising object. These can describe the circumstances around someone without being a persistent audience key themselves.

This matters when reading a network request. A long string is not automatically a person identifier. Ask what it names, who issued it, whether it repeats and what a recipient can connect to it. A campaign ID shared across thousands of impressions has a different role from a browser key attached to one continuing history.

Keep the five operations separate

Collection creates or receives a record. Recognition treats a present record as a previously encountered unit. Matching connects records; identity resolution organises those links into a view of an account, device, household or person. Targeting selects eligible opportunities. Measurement connects exposure and outcome evidence under stated rules.

Different organisations can perform different operations on the same journey. A platform may recognise an account, select an ad and report aggregate results while the advertiser receives only a click reference and a subsequent order. There is no single, complete identity record shared by everyone involved.

Start with the runtime, then the hardware

A runtime is the environment executing the code: a browser page, a native app or an embedded webview. A mobile website and a native app on the same phone do not automatically share identifiers. The website does not gain access to the phone’s advertising ID simply because it is viewed on a phone.

Useful device descriptions have several layers: hardware, operating system, runtime, service, account state and available permissions. “An authenticated broadcaster app on a shared Android TV” tells us much more than “video on mobile and TV”. It also identifies where an implementation needs to be checked.

Browsers recognise stored contexts

Websites use permitted browser storage and server records to recognise activity. A browser profile can hold separate values for separate sites. Private browsing, separate profiles, storage deletion, expiry and tracking protections change that continuity. Moving from a laptop browser to a phone browser creates no automatic connection between the two.

Signing into the same service can provide an account relationship across those contexts. The service must actually record and use that relationship. Browser protection does not erase an existing customer database, and a customer login does not grant every embedded advertising provider access to that database.

• WebKit: tracking prevention and storage boundaries
• WHATWG: browser storage and origin boundaries

Native apps have platform-specific scopes

Apps can use account and installation identifiers alongside platform APIs. Apple’s IDFA depends on App Tracking Transparency permission where required. ATT also covers qualifying tracking using substitute identifiers such as hashed emails. It is not merely an IDFA switch. Apple’s IDFV is scoped to a vendor and device, with its own lifecycle and permitted uses.

On Android, the advertising ID discussed here is supplied through Google Play services. Access depends on the platform, app configuration and user controls. App installation IDs serve a narrower purpose. Hardware serial numbers, IMEI and network-interface addresses are not interchangeable advertising IDs; access restrictions and platform rules matter.

• Apple: tracking, IDFA, IDFV and webviews
• Apple: identifierForVendor scope and lifecycle
• Android: choosing and using identifiers

Embedded browsers create a boundary

A link opened inside a social or news app can run in an embedded webview, a browser component or the external browser. Storage sharing depends on that component and its configuration. The familiar-looking page does not establish that its cookies match those in the standalone browser.

An app may explicitly pass a permitted value into a webview or a link. That is an implemented data transfer, not a property of the hardware. Trace the actual hand-off. Apple also applies its tracking rules to webviews used for app functionality, with a distinction for enabling navigation of the open web.

• Apple: tracking, IDFA, IDFV and webviews

Shared screens and other connected devices

A television, streaming stick or games console may expose a platform advertising identifier, an app-specific identifier and an authenticated service account. The availability and controls vary. A device identifier cannot tell whether nobody, one person or a family watched the screen. Viewing profiles help describe service use, but they are not continuous verification of the audience.

Smart speakers, vehicle displays, wearables and digital outdoor screens belong in the same framework. Start with the actual service and delivery architecture. Do not assume they offer a phone-style advertising ID. Some opportunities are selected by location, schedule or content; some are linked to accounts; some reach a shared audience without identifying individual recipients.

• Roku: advertising and app-specific identifiers

Tags, pixels, SDKs and APIs perform different jobs

A web tag is code or configuration executed in a page. A tag manager helps deploy it. A literal tracking pixel is an image request, but “pixel” also names larger advertising libraries that observe events, read available values and send requests. The label alone tells us little about the payload.

An app SDK is software integrated into a native application. A server API accepts events from another system, such as an ecommerce backend or CRM. These routes can report the same purchase. Unless the integration supplies the correct deduplication keys and follows the recipient’s rules, one real event can become several recorded events.

Storage is not transmission

A cookie is a stored name-value pair with access and delivery rules. Local storage is a different browser facility. A URL parameter travels in an address. A customer ID may exist only in a server database. An identifier is the value or meaningful part of a value, rather than the container holding it.

First-party and third-party describe context, not whether a company is trustworthy or whether data stays inside the organisation. Third-party code running in a page may handle a value from the site’s first-party context and send it elsewhere. Partitioning separates third-party storage by the top-level site, limiting reuse of that storage across sites.

• WebKit: tracking prevention and storage boundaries
• WHATWG: browser storage and origin boundaries

Read the complete event, including the connection

A request can carry an event name, timestamp, page address, product, order value and available identifiers. Other information arrives through headers or the network connection. The receiver’s immediate peer has an IP address, but a proxy, relay or server integration may sit between that receiver and the original browser.

A server can explicitly forward permitted client context, including an IP or user-agent field. That must be distinguished from the server’s own connection. Inspect fields, destinations and configuration together. A harmless-looking event name says little if a page URL or custom field also contains a customer detail.

• Google: server-side tagging architecture
• Meta-maintained code: fbp, fbc and event mapping

Server-side routing changes control and visibility

With server-side tagging, the browser or app sends information to a server endpoint, which processes it and may forward selected fields. This creates an opportunity to validate, remove or transform data before another recipient receives it. It also creates another system whose logging, access, retention and forwarding rules need to be understood.

The server can report an order even when a browser tag did not run, if it has the necessary event and permitted matching inputs. It cannot recover evidence it never received. Moving an email hash or browser identifier through a first-party endpoint does not itself anonymise that value.

• Google: server-side tagging architecture

Permissions must affect the actual data flow

Collection, storage, transmission and later use are distinct decisions. A consent interface is only one part of the implementation. Check the initial state, each changed state and every independent integration. A web tag’s settings do not automatically control a CRM export or a server purchase feed.

Google’s basic consent mode blocks its tags until consent is granted. Advanced mode loads tags with defaults and can send cookieless pings when storage consent is denied. That is product-specific behaviour, not a statement that no data moves or that the configuration satisfies every legal obligation. The payload and permitted purpose remain the evidence.

• Google: basic and advanced consent mode

Browser and publisher keys

A browser key usually recognises a stored context within a site or supported network. Its usefulness depends on whether it can be written, read and delivered again. Cookie deletion can interrupt recognition without deleting historical records held by the recipient. A new key does not prove a new person.

• Google Analytics: browser and app identifiers
• Google tag: supported client_id retrieval
• Meta-maintained code: fbp, fbc and event mapping

App and platform identifiers

Advertising identifiers are platform facilities with platform rules. Installation, vendor and advertising IDs answer different questions. Missing or all-zero values are not a shared audience identifier: treating them as a key would merge unrelated devices. Record the reason for unavailability where the API provides it.

• Apple: tracking, IDFA, IDFV and webviews
• Android: choosing and using identifiers
• Apple: identifierForVendor scope and lifecycle
• Google Analytics: browser and app identifiers
• Roku: advertising and app-specific identifiers

Interaction and conversion references

These values help connect advertising interactions with later events. Their documented purposes differ. Preserve the original field and case where required, use the matching destination field, and follow the selected product’s import rules. A retained value is not a guarantee that a conversion remains eligible for attribution.

• Google: GCLID definition
• Google: GCLID generation and reuse
• Campaign Manager 360: enhanced attribution and DCLID
• Microsoft Advertising: click identifiers and event inputs
• Meta-maintained code: fbp, fbc and event mapping
• Google: GBRAID scope
• Google Ads API: app and web conversion reference fields

Customer keys and identity services

A CRM key belongs to the organisation’s customer model. Email addresses and phone numbers offer contact-based joins, subject to compatible preparation and permitted use. An identity service adds its own processing, graph or interoperability layer. It does not turn every participating record into a verified human.

• UID2: identifier and encrypted token creation
• LiveRamp: RampID types and match-rate definitions
• ID5: observed and probabilistic matching signals

Signals are evidence, not ready-made identities

IP address, user-agent, approximate location, language and device configuration can contribute to recognition or inference. Their precision, stability and availability vary. Several people may share a network address, while one device can change networks. Combining signals can narrow possibilities without guaranteeing a unique or enduring match.

Keep those signals separate from inventory identifiers such as seller, placement and creative IDs. Then document the actual join. A reference library is useful when it explains what a value can do, rather than giving every long string the same identity powers.

• W3C: browser fingerprinting and its limitations
• IAB Tech Lab: OpenRTB objects and fields

Exact matching starts before the hash

Two systems can compare a shared customer key or compatible representations of a contact point. With email matching, the input is prepared under the destination’s rules before hashing. Trimming whitespace, handling case and applying provider-specific address rules can change the result. Phone numbers also need an agreed representation.

SHA-256 produces a fixed-length digest. The same prepared bytes produce the same digest; different normalisation or encoding can prevent a valid match. A different salt or key can also prevent comparison. Apply the receiving product’s specification rather than a universal “hash customer data” recipe.

• UID2: normalisation, hashing and encoding

Hash equality is not human identity

Matching full cryptographic digests gives strong evidence of the same prepared input. It does not prove that only one person uses the email address. A shared inbox, an old customer record or a recycled contact point can produce an exact technical join with the wrong interpretation.

Hashing is also not encryption. A recipient does not need to reverse a hash if it can prepare and hash candidate addresses and compare the results. The practical question is which candidates, mappings and supporting records are available. Replacing readable text with a digest can support useful controls without resolving the entire privacy question.

Observed and inferred links need different evidence

An observed login can link a browser session to an account. A shared customer key can link two permitted datasets. These are commonly described as deterministic links. The method can be exact while the account is shared, the source data is stale or the claimed person relationship is wrong.

Probabilistic resolution estimates a relationship from signals such as network, timing or device patterns. A threshold determines which candidates are accepted. Raising it may reduce false joins while missing more genuine relationships. A household inference should remain a household inference as it moves downstream; it should not quietly become a verified person match.

• ID5: observed and probabilistic matching signals

A graph needs a memory of why it believes a link

An identity graph represents records as nodes and relationships as edges. Each edge needs evidence, a date, a scope and a way to expire or be removed. Two identifiers appearing in the same database do not establish a relationship. An observed account login, a permitted shared key or a documented inference supplies the missing explanation.

Translation adds another dependency. A publisher key, an identity-provider token and a DSP key may require supported mappings. A match in one system does not guarantee that a destination can resolve or activate it. Graph changes, opt-outs and expired mappings can alter that result even if the original input has not changed.

• UID2: identifier and encrypted token creation
• LiveRamp: RampID types and match-rate definitions

Match rate, accuracy and reach answer different questions

Match rate measures successful joins against a specified input denominator. Accuracy asks whether those joins are correct. Reach concerns the distinct units actually reached, or estimated to have been reached, during delivery. These figures cannot substitute for one another.

Ask whether the denominator counts submitted rows, valid contact points, deduplicated customers or devices. A customer with three addresses can contribute several rows. A matched account may be inactive or unavailable on the selected inventory. Improving the advertised match rate by accepting weaker links can increase errors without adding useful reach.

• LiveRamp: RampID types and match-rate definitions

Clean rooms control collaboration, with different outputs

A clean room is an environment for controlled collaboration between datasets. Controls can govern join columns, queries, minimum group sizes, outputs and access. AWS, for example, supports aggregation rules, approved custom analysis and list rules that can return row-level overlaps. “Clean room” therefore does not mean every output is aggregated.

Assess what enters, who can query, what leaves and what repeated queries can reveal. A permitted join can support measurement or audience activation without each party receiving the other’s entire database. It still needs an appropriate purpose, sound source data and controls suited to the actual disclosure and inference risks.

• AWS Clean Rooms: analysis rules and permitted outputs

Begin with the reason for eligibility

Contextual targeting selects an opportunity because of the current content or setting: a search query, a recipe, a sports stream or a location. It can work without a persistent audience history. Geographic targeting may use declared or inferred location; a location rule does not necessarily establish a home address.

Behavioural targeting uses recorded or inferred activity. Retargeting uses an earlier interaction that can be linked to the present opportunity. Customer-list targeting starts with records supplied through a supported matching process. Declared attributes come from information someone supplied; inferred attributes come from a model. Those sources carry different assumptions.

A matched audience is different from a predicted audience

An uploaded customer list can produce a matched set recognised by a platform. A modelled audience can seek other accounts or opportunities expected to behave similarly. Broader automated delivery may use audience inputs as signals rather than a strict boundary. The campaign type and current control determine which interpretation is correct.

A propensity score predicts an outcome, such as a purchase or completed view. It does not necessarily establish civil identity or membership in the original customer list. The advertiser may see a segment name and aggregate results while the platform performs its own matching and prediction internally.

• Google Ads: Customer Match

Delivery has several gates

First, an opportunity must satisfy the relevant inventory, geographic, audience, policy and creative conditions. An auction or allocation process then decides which eligible ad is delivered. Bids, predicted outcomes, ad quality and commercial rules can affect that decision. Budget and pacing determine how spending is distributed over time.

Identity can affect several gates, but it does not replace them. A recognised customer might be excluded because they already purchased, lose an auction to another advertiser or never visit the available inventory. An exclusion is also a matching operation: it can fail to cover an unrecognised browser or an account absent from the exclusion list.

• Google Ads: eligibility and Ad Rank

Frequency depends on the unit being counted

A frequency cap needs a unit, a period and a scope. Three impressions per browser in a campaign is different from three per account across several devices. Separate platforms may maintain separate counters. Shared devices and missing joins make person-level interpretation more difficult.

Some systems count available identifiers and some support modelled frequency controls when identifiers are absent. Display & Video 360 documents both approaches in supported inventory. A cap is therefore a delivery control with stated assumptions, not proof that a particular human saw an exact number of advertisements.

• Display & Video 360: counted and modelled frequency controls

Optimisation learns from the outcomes it receives

A conversion signal can help a system predict which future opportunities are valuable. The identifier used for that feedback need not be the identifier used to select the original impression. A browser event, contact match or eligible interaction reference can supply different pieces of the measurement record.

The objective matters as much as the join. A campaign optimised for form submissions can find people likely to submit forms, including poor-quality leads. Passing suitable later outcomes can change the available learning signal. Reporting still needs to distinguish recorded and modelled outcomes, and attribution still does not establish that the advertising caused them.

The query supplies the immediate context

Someone searching for a washing-machine repair has supplied a useful commercial signal before an advertiser knows anything else about them. The query, location, device and other auction context can help determine whether an ad is eligible and how it ranks. Google describes Ad Rank as a combination of bids, quality, thresholds, competition, context and the expected impact of assets. The highest bid is not a complete explanation of the result.

• Google Ads: Ad Rank

The platform and advertiser see different identities

A search service may recognise its signed-in account or browser. The advertiser has its own customer records and website identifiers. Those are separate views. A customer-list integration can establish a permitted match between submitted customer data and platform records, allowing supported audience uses without handing the advertiser a directory of platform users. A match is useful for eligibility, exclusion or bidding; it is not evidence that every person on the list received an ad.

• Google Ads: Customer Match

An audience setting can change reporting or reach

In Google Ads, Observation reports on selected audiences without itself restricting reach to those audiences. Targeting restricts the eligible audience where the setting is supported. First-party audience data can also inform automated bidding. The practical question is whether the audience is a hard condition, a reporting lens or an input to a prediction. Treating all three as a list of people who will see the ad leads to bad campaign analysis.

• Google Ads: targeting and observation

Click and customer joins connect outcomes

An eligible click can carry a click reference to the landing page. A configured implementation captures it and connects it to a later conversion. A lead-generation business may retain the reference with a CRM lead and upload a qualified sale through a supported conversion integration. Customer-data matching provides another route where supported. The record needs the right event information and must meet the applicable timing, consent and product requirements. A cookie remaining on a device does not extend an import deadline.

• Google Tag Manager: Conversion Linker
• Google Data Manager: offline conversions

Read the result at the level actually measured

A reported sale means the measurement system credited a qualifying event under its rules. It does not establish why the person searched, whether another campaign created demand, or whether the purchase would have happened anyway. Brand searches and returning customers make this especially important commercially. Query reports, customer outcomes and controlled tests answer different questions; none should silently stand in for the others.

Accounts create continuity inside the service

A social service can organise activity around its own accounts: content interactions, followed accounts and responses to ads. These observations can inform predictions without becoming verified facts about a person. Watching several running videos is evidence of that account’s activity. It does not establish that its operator is a runner, owns running shoes or is ready to buy. Meta’s description of ad retrieval illustrates how large candidate sets are narrowed before later ranking stages.

• Meta: ad retrieval and ranking

Advertiser events extend the view

A website tag, app SDK or server API can report events such as a product view or purchase. Event data and matching information perform different jobs: one describes what happened; the other helps the recipient connect the event to existing records. In Meta integrations, _fbp and _fbc are browser cookie names, while fbp and fbc are API fields. A server may construct fbc from an observed fbclid. Calling an event “server-side” does not establish anonymity or remove the need for permitted data use.

• Meta: Conversions API integration code

Matching, deduplication and prediction are separate

Consistent event names and a shared event identifier can help prevent one purchase reported through two routes from being counted twice under the product’s deduplication rules. That is event deduplication. Recognising a customer is a different operation. Predicting that another account is likely to purchase is different again. Customer lists, website audiences and modelled expansion may all influence delivery, but an expanded audience should not be described as a successful customer match. The campaign’s actual controls determine how tightly an audience constrains delivery.

• Meta: Conversions API integration code
• Meta: ad retrieval and ranking

Platform identity does not travel everywhere

A logged-in social account inside an app does not automatically make its identity available to an advertiser’s website opened in another browser. A click, permitted tracking signal or subsequent customer interaction may create a link, but that link needs an actual mechanism. Apple’s tracking rules also apply to relevant cross-company data uses, not just access to IDFA. Replacing a device advertising identifier with a hashed email is not a blanket exemption.

• Apple: tracking permission and data use

Delivery and reporting have narrower meanings

An advertiser buys an opportunity selected by the platform, not possession of the platform’s account graph. Reporting may combine attributed and modelled outcomes under product-specific rules. Seeing an ad after discussing a product does not reveal the route that selected it: context, broad eligibility, past activity, a supplied list or a prediction could produce a similar result. Good analysis starts with configured inputs and event diagnostics instead of guessing from one impression.

Start with the publisher’s relationship

A publisher knows the page being read and may recognise a browser, subscriber or registered account. Those are different strengths of evidence. A cooking article can support a contextual placement even when the reader is unknown. A signed-in subscriber may support a publisher audience built from permitted activity. Neither fact automatically gives every advertising partner the same identifier, the underlying email address or the full reading history.

• Google Ad Manager: publisher provided identifiers

Local identifiers need a route to become useful elsewhere

An identifier meaningful to one publisher is not automatically meaningful to a buyer. The publisher can use it internally, translate it through an agreed integration or pass an eligible identity signal. Google Ad Manager’s publisher provided identifier is one documented example, available to eligible Ad Manager 360 implementations. Its documented uses include audience controls and frequency management; Google expressly distinguishes those capabilities from its reach reporting and conversion tracking support.

• Google Ad Manager: publisher provided identifiers

Browser boundaries shape recognition

Cookie matching associates identifiers from separate advertising systems where the required browser storage and requests are available. It does not let one domain freely read another domain’s cookie store. The association is maintained in a match table. Browser restrictions, partitioned storage, expiry and user choices can break continuity. A reader recognised on one site may therefore be unknown to a buyer on another site, even on the same computer.

• Google Authorized Buyers: cookie matching
• WebKit: tracking prevention

Display and native describe presentation

A display placement may contain an image or rich creative. Native advertising supplies assets for presentation within a publisher’s layout. Either can be selected using context or an eligible audience signal. The format does not determine the identity method. A direct publisher agreement and a programmatic purchase can also reach the same type of placement through different commercial and technical routes. Record the publisher, placement, buying route and audience method separately.

• IAB Tech Lab: OpenRTB 2.6

Count exposure before explaining outcomes

An ad request is an opportunity to make a decision. It is not yet evidence that the creative appeared in a viewable area. Impression, viewability and click measurements describe different events. A later conversion join adds another dependency on available identifiers and attribution rules. For a publisher audience, the useful questions are how the segment was formed, how recently membership was assessed, what proportion of inventory can carry it and which party can verify delivery.

• IAB Tech Lab: Open Measurement SDK

The transaction and the audience are different

A publisher offers inventory, a supply platform makes opportunities available and a demand platform evaluates purchases for advertisers. An exchange may connect the parties. These roles can sit within one company or several companies. A deal can define eligible buyers, price or inventory without defining a person. The commercially useful starting point is what is being sold, who can buy it and what information reaches the decision-maker.

• IAB Tech Lab: CTV programmatic guide

A bid request describes an opportunity

OpenRTB separates the impression opportunity, media context, device information and audience information. A bid-request ID identifies a transaction; a creative ID identifies an ad; a deal ID identifies commercial terms. None is a consumer identifier merely because it appears in an advertising message. Optional audience fields may carry an exchange identifier, a buyer mapping or extended identifiers from recognised sources.

• IAB Tech Lab: OpenRTB 2.6

Receiving an ID is not the same as resolving it

A buyer needs to understand the identifier’s namespace and have a usable relationship to it. A match table may translate one system’s value to another. An identity service may provide a supported token. The provenance of that link matters: observation of a shared authenticated key and inference from a pattern of signals are different evidence. An extended-ID field establishes a place to carry a value; it does not independently certify the match or the person behind it.

• Google Authorized Buyers: cookie matching
• IAB Tech Lab: identifier provenance

Audience eligibility is one buying condition

A demand platform can evaluate content, supply quality, price, geography, campaign budget and an available audience signal. A recognised ID may allow a list lookup or frequency decision. Missing identity can narrow those capabilities without making the inventory impossible to buy. Frequency controls also vary by product: DV360 documents modelled approaches for some inventory without IDs, alongside different requirements for capped connected-TV buying. A single universal “three ads per person” claim is therefore misleading.

• Google DV360: frequency caps

Follow the chain through to a measured result

An accepted bid, a delivered creative and a measured impression are separate events. Contracted billing rules specify which event incurs cost. Measurement then assesses matters such as viewability, invalid traffic and attributed outcomes. Identity quality is one part of buying quality; a perfectly matched browser still has little commercial value if the ad never has a valid opportunity to be seen. Supply-chain transparency and audience accuracy deserve separate checks.

• IAB Tech Lab: Open Measurement SDK

The format does not specify the identity

A video can play inside a desktop browser, a mobile app or a television app. The content may be identical while the available browser storage, app identifiers and account relationships differ. Start with the service and playback environment, then identify the actual signals. Describing every video impression as “digital” conceals the practical differences that decide whether an audience match or cross-device connection can work.

• Google Ads: video targeting methods
• IAB Tech Lab: CTV programmatic guide

Content selection and audience selection coexist

An advertiser can want a particular context, such as cooking content, or an audience, such as eligible past customers. Some products support both; campaign objectives and formats affect the available controls. Google’s video documentation distinguishes audience methods from content methods and records restrictions on content targeting for conversion-focused video campaigns. A buyer should therefore confirm the active campaign’s eligibility rules rather than assume every targeting option is available in every product.

• Google Ads: video targeting methods

Serving instructions are not viewer identity

VAST provides a standard way to describe video advertising assets and tracking instructions. A creative identifier helps recognise the ad; event tracking helps recognise what the player or delivery system reports. Neither is automatically an identifier for the viewer. Client-side and server-side insertion can place different systems between the viewer and the ad server, so the source of an event and any forwarded context must be understood.

• IAB Tech Lab: VAST 4.3

A completed video is still a measured event

Start, progress and completion events can describe playback. Viewability asks another question about the opportunity to see the ad. Open Measurement supplies supported environments with a common measurement integration for third-party verification. Neither a complete playback nor a viewable impression proves attentive human viewing. A television left running and a mobile video watched closely can produce superficially similar completion figures with very different commercial value.

• IAB Tech Lab: Open Measurement SDK

Reach and conversion require further connections

Repeated exposure can be counted against an available account, browser or device key, or estimated through a documented model. Deduplicating across services requires an additional common relationship or modelling method. The same applies when a video view is credited with a later purchase on another screen. A platform may have a permitted internal link that the advertiser cannot inspect directly. Reports should say what was observed, what was inferred and which inventory is covered.

• Google DV360: frequency caps
• Google DV360: co-viewing estimates

Several identities can sit behind one screen

A smart TV or attached streaming device may provide an advertising identifier under its platform rules. A streaming service may recognise an account or selected profile. The advertising system may also receive app, content and network information. An account can operate on several devices, while a television can serve several people. The question is which entity a particular field recognises, not whether the sales description calls the inventory addressable.

• IAB Tech Lab: CTV programmatic guide

Ad insertion changes the route

With server-side ad insertion, a service combines advertising with the content stream. An ad request can consequently originate from an insertion server. Its connection address is not automatically the viewer’s IP address. A system may deliberately forward viewer context where supported and permitted, and playback reporting can involve the client, server or both. Inspect those routes before claiming that an ad server directly observed a household or a completed view.

• IAB Tech Lab: VAST 4.3

Household graphs need evidence

A vendor may associate devices through authenticated relationships or infer a household from observed signals. A shared public IP address alone has limitations: networks can be shared, addresses can change and intermediaries can obscure the originating device. Even an accurate household association does not establish who was present for a particular programme. The graph’s evidence, refresh schedule and permitted uses matter more than the appealing simplicity of a single household label.

• IAB Tech Lab: identifier provenance
• IAB Tech Lab: CTV programmatic guide

Frequency and co-viewing answer different questions

A frequency cap may operate on a supported device or other key within a product’s coverage. It cannot automatically constrain all exposure across unrelated services. Co-viewing estimates the additional people watching a shared screen. Google documents survey and modelling inputs for that purpose. Keep device impressions, estimated households and estimated people separate in reporting. Dividing impressions by an estimated audience does not turn that estimate into observed person-level frequency.

• Google DV360: frequency caps
• Google DV360: co-viewing estimates

TV hardware may have its own data relationship

Some televisions offer automatic content recognition, or ACR, to recognise viewing content under the manufacturer’s settings and permissions. Samsung documents viewing-information controls for supported products. This is an additional collection relationship, not a feature inherent in every connected-TV impression. The hardware manufacturer, streaming service and advertising buyer can each hold different information. A claim about one participant’s capabilities should not be silently transferred to the others.

• Samsung: viewing recognition controls

The broadcaster supplies the service relationship

In Australia, BVOD commonly describes broadcasters’ internet-delivered video services, including on-demand programmes and live streams. A service such as 9Now is available on supported smart TVs as well as other environments. BVOD therefore overlaps with connected TV when watched on a television. It is also online video when watched elsewhere. These labels describe different dimensions and should not be treated as mutually exclusive audience buckets.

• 9Now: supported smart TVs
• Nine: programmatic trading across streaming services

Registration supports a service account

Registration can let a broadcaster connect activity to an account across supported sessions or devices. It does not establish the identity of every viewer using that account. Declared registration attributes, observed viewing and inferred interests also have different evidential strength. The commercial value is continuity within a defined service relationship. That continuity still depends on sign-in, implementation, permissions and the surfaces included in the broadcaster’s product.

• Nine: audience and matching products

Audience products add selection and matching

Nine describes first-party audience segments and Audience Match integrations that allow advertisers to activate eligible customer audiences. These are examples of a broadcaster’s documented products, not a certification of match accuracy or a universal specification for BVOD. An advertiser should distinguish a broadcaster-defined segment, a matched customer list and a modelled extension. Each answers a different question about who is eligible to receive the campaign.

• Nine: audience and matching products

The buying route can change access

Broadcaster inventory can be traded through several arrangements. Nine documents programmatic access spanning 9Now and other streaming services. A buyer still needs to establish which inventory, identifiers and audience controls are available through the chosen route. A direct relationship may expose different reporting or planning options from a DSP deal. A common seller or buying interface does not, by itself, prove that every underlying service shares the same identity coverage.

• Nine: programmatic trading across streaming services

Cross-broadcaster reach needs an extra method

Two broadcasters may each report a recognised account and a valid ad exposure. Adding their account counts does not establish unique people across the campaign. Deduplication needs an agreed matching relationship or an explicit audience measurement model. The same applies to linking BVOD exposure with linear television, retail sales or website conversions. Ask which unit is being counted, which records can be connected and how unmatched viewing is represented before comparing suppliers.

• Google DV360: co-viewing estimates

Commerce data describes a relationship

A retailer may recognise a shopping account, loyalty membership, browser session or transaction. A product search and a previous purchase supply different signals: one expresses current interest, while the other records an earlier outcome. A loyalty account can also be shared. Treating every purchase as the preference of one verified individual can produce confident but incorrect audience labels. Product IDs and order IDs identify merchandise and transactions, not necessarily customers.

• IAB: retail media buying guide

Onsite, offsite and in-store are different environments

Onsite advertising appears on the retailer’s digital properties. Offsite activity uses retailer audiences or measurement relationships beyond those properties. In-store media operates in a physical retail environment. A sponsored product beside a relevant search can use shopping context; an offsite audience campaign needs a supported activation route; a shared store screen may have no individual addressable recipient. One retail-media budget can therefore contain several quite different identity systems.

• IAB: retail media buying guide
• IAB and IAB Europe: in-store definitions and measurement

Audience activation needs an actual bridge

To reach an eligible customer outside its own property, a retailer needs a relationship that the destination can use, such as supported customer-data matching or an identity-provider integration. A brand’s CRM list is a separate data asset and may overlap only partly. Clean rooms can support controlled comparisons, but their existence does not guarantee a high match rate or permission to activate every record. Specify what leaves each party, who can join it and what outputs are available.

• IAB: retail media buying guide

Closed-loop measurement still uses rules

A retailer can connect qualifying ad interactions with purchases it observes. This gives measurement a valuable commercial outcome, but attributed sales depend on windows, eligible products, return handling and the selected attribution method. Amazon’s documentation distinguishes campaign attribution from total retail sales. Its separate Amazon Attribution product measures eligible non-Amazon campaigns leading to Amazon outcomes. Neither product description should be read as visibility into every purchase made elsewhere.

• Amazon Ads: campaign attribution
• Amazon Ads: measuring non-Amazon campaigns

The missing sales matter

An analysis limited to one retailer excludes purchases it cannot observe or connect. It can also favour existing customers who were already likely to buy. A matched transaction supports an outcome record; incremental sales require an additional causal method. For commercial comparison, align the measured products, customer coverage, sales basis and campaign objective. A high return on attributed spend and a small effect on total category demand can coexist.

Streaming services can recognise their own accounts

A streaming service can use its first-party account and listening signals within its advertising products. Spotify documents demographic, contextual and interest-based options, together with supported advertiser and partner audience data. A music preference or listening pattern is a targeting signal, not a verified personal characteristic. Product availability depends on the buying route and market. The advertiser may receive campaign results without receiving the service’s underlying account identity or listening history.

• Spotify: interest and behavioural targeting
• Spotify: targeting options

An RSS download has a different observable record

Podcast hosting measurement commonly starts with server logs for downloaded or progressively downloaded files. IAB Tech Lab’s v2.3 guidelines define filtered downloads, audience measures and ad delivery for that context. A hosting server generally does not receive the same playback feedback as an integrated streaming player. File delivery therefore needs to remain distinct from proof that somebody heard the ad.

• IAB Tech Lab: podcast measurement v2.3

Network signals support estimates with limits

The guidelines use IP address and user-agent information in deduplication, with filtering and special treatment of shared networks. Those signals are not a permanent person identifier. Changing networks can fragment records; shared addresses and similar devices can merge them. Dynamically inserting an ad into an episode also does not, by itself, establish a persistent listener identity.

• IAB Tech Lab: podcast measurement v2.3

The content relationship is useful in its own right

An advertiser can choose a programme because its subject, presenter and audience fit the offer. That decision need not start with an individual listener match. A sponsorship and an audience-targeted insertion answer different buying questions, even if both sound like a host reading the same script. Keep the creative format, selection method and delivery mechanism separate when assessing what data the campaign actually needed.

• IAB Tech Lab: podcast measurement v2.3
• Spotify: targeting options

Response is a separate piece of evidence

A listener may visit a website, search for the brand or use a promotional code later. A code records an attributed response route, but it can be shared beyond the intended audience. A matched web conversion requires an additional connection between exposure and the responding environment. For that reason, campaign reports should label downloads, reported playback, attributed responses and experimental lift separately. Comparing them as if they were all people who listened obscures the actual evidence.

The game and the advertising SDK have different roles

A game may recognise a local player record or a signed-in account. An advertising SDK requests and reports ads using the data available to its integration. A console game, mobile app and browser game do not inherit the same identifiers. An app’s ability to recognise its own player also does not automatically authorise cross-company tracking. Permissions, platform rules and the actual data flows determine what the advertising partner can use.

• Apple: tracking permission and data use

The ad experience changes the measurement

Interstitial ads occupy a break in the experience. Rewarded ads offer an in-game benefit for a qualifying interaction. Intrinsic ads appear within the game environment, such as a virtual trackside board. Sponsorships can involve deeper integration. The IAB gaming framework distinguishes formats and appropriate metrics. A video-completion measure suited to one format is not sufficient to explain whether an in-world display was visible during play.

• IAB: gaming measurement framework
• IAB: gaming creative and measurement guidance

A reward identifier identifies the reward

Google AdMob’s server-side verification can notify a game server about a qualifying rewarded interaction through a signed callback. Its transaction_id identifies a reward-grant event, while an optional user_id is supplied by the app. These fields have different jobs. A signature helps verify the callback’s authenticity. It does not identify the human holding the device or establish that the advertiser has permission to build a cross-app profile.

• Google AdMob: reward verification

Intrinsic visibility needs the game’s geometry

A virtual billboard can be loaded into a scene while the player looks elsewhere. Measuring the opportunity to see it therefore requires evidence about its presentation, not just successful asset delivery. The IAB guidance describes impression and viewability measurement for intrinsic display and video. A commercial report should retain the distinction between served assets, qualifying impressions, viewable exposure and any additional attention measure instead of using “engagement” for all of them.

• IAB: gaming creative and measurement guidance

Acquisition measurement may use another system

An ad for a game and an ad inside a game are different campaign situations. An install or later purchase needs a supported attribution route. Apple’s AdAttributionKit provides attribution mechanisms designed to protect privacy rather than exposing a universal cross-app person ID. Where aggregate or restricted reports replace event-level connections, the loss of detail is part of the measurement design. A missing device identifier should not be treated as permission to construct a prohibited substitute.

• Apple: AdAttributionKit
• Apple: tracking permission and data use

The addressable object can be the screen

A station panel, roadside display or supermarket screen can have a stable inventory identity. That lets a buyer select the place and time of an ad without identifying everyone nearby. A screen’s location describes the advertising environment; it is not automatically a location observation about an individual. Digital delivery and programmatic buying do not turn a shared display into a personal device.

• IAB: digital out-of-home and in-store media

Audience planning can remain at group level

A campaign can select commuter locations, store zones, dayparts or other contextual conditions. Audience research may estimate the composition or volume of people likely to encounter the display. The result is a buying decision about an opportunity, not necessarily a list of known recipients. If a supplier adds mobility data, customer matching or another individual-level source, that is an additional collection and modelling relationship that should be described separately.

• IAB: digital out-of-home and in-store media
• IAB and IAB Europe: in-store definitions and measurement

One play can represent several estimated impressions

OpenRTB includes a DOOH object for the placement and a quantity object for the impression multiplier. That mechanism allows one bought opportunity to represent more than one billable audience impression under the agreed measurement. The multiplier has a source; it is not a roster of people observed looking at the screen. A play count and an estimated audience-impression count should therefore remain separately labelled.

• IAB Tech Lab: OpenRTB 2.6

Proof of delivery has a limited scope

A screen operator’s playback record can show that the scheduled creative ran under the system’s reporting rules. It does not, on its own, establish who passed the screen, who could see it or who paid attention. Audience estimation introduces further assumptions about traffic, timing and exposure. The useful commercial comparison is between methods with clearly stated units and coverage, not between impressive totals whose underlying definitions differ.

Outcomes require another study or connection

A later store visit or sale cannot be read directly from a screen’s playback log. A measurement partner may propose a separate exposed-group estimate, permitted matching process or controlled geographic study. Each needs its own evidence and limitations. A QR-code response creates a new digital interaction; it does not retrospectively identify every passer-by. Keep the response record, audience estimate and ad-play record distinct before drawing conclusions about performance.

First establish what was observed

A purchase record establishes that a system recorded a purchase. A browser event establishes that code sent an event. Neither automatically establishes a fulfilled order, a new customer or a profitable sale. Useful measurement begins by defining the outcome and reconciling it with the business record.

An available click reference can connect a later outcome to an advertising interaction. A permitted account or customer-data match can support another route. View-through measurement links an eligible impression with a later outcome within the product’s rules. The join may concern a browser, account, device or household. Its scope should travel with the result.

• Google Data Manager: offline conversions
• Google Tag Manager: Conversion Linker

Count the event once

A website may send the same purchase through a browser tag and a server API. Those are two deliveries of evidence about one order. Where supported, an event identifier lets the receiving platform recognise duplicate submissions. A customer identifier has another job: it connects records associated with a customer or contact point.

Deduplication depends on the receiving product’s event fields and rules. Reusing one event ID for different orders can collapse real sales; generating a new ID for every retry can inflate them. Refunds, cancellations and later value adjustments also need a defined treatment. Better matching cannot repair an incorrectly defined conversion.

• Google Data Manager: event identity and deduplication

Keep the clocks separate

Storage retention determines how long a value remains available. A conversion window determines which later outcomes are eligible for credit. An import deadline determines whether a platform will accept a submitted event. Reporting dates, time zones and processing delays add further differences. Extending a database’s retention does not extend the platform’s attribution window.

Two platforms may claim the same order because each observed an eligible interaction and applied its own rules. Adding their attributed totals will not necessarily produce the number of orders in the business. Reconcile outcome definitions, dates, attribution models, windows and duplication before interpreting the gap as tracking failure.

• Google Ads: conversion windows
• Google Data Manager: offline conversions

Read modelled totals as estimates

When direct linkage is unavailable, a platform may estimate the missing contribution from observed patterns. Google documents consent-mode conversion modelling in eligible accounts and includes modelled results in conversion reporting. This does not reveal the missing person’s actual path to purchase.

Aggregate and on-device attribution can deliberately limit the information returned to advertisers. Depending on the product, reports can contain delayed, reduced or thresholded information. Ask whether a metric counts observed events, allocates attributed credit or includes estimated outcomes. A dashboard can display all three with equal numerical confidence.

• Google Ads: consent-mode conversion modelling
• Apple: limited attribution postbacks

Ask the causal question separately

Incrementality asks how many outcomes occurred because of the advertising. A well-designed randomised holdout compares comparable groups assigned different advertising conditions. The effect is an estimate for that experiment’s population, period and treatment, with uncertainty. It does not identify which individual orders were caused by the campaign.

Marketing-mix modelling can estimate channel effects from aggregate observations. Its causal interpretation depends on assumptions about confounding, seasonality, delayed effects and the model itself. A good statistical fit is insufficient proof. I would use attribution to understand recorded journeys, experiments to test incremental effects, and modelling to inform broader allocation decisions.

• Google Ads: conversion lift experiments
• Google Meridian: causal assumptions in MMM

An identifier has a lifecycle

A browser value can disappear when storage is cleared, expire, become inaccessible in another context or be prevented from being created. Partitioning can give an embedded service separate storage under different top-level sites. The same person can consequently appear as several unrelated browser records.

Accounts and devices change too. People log out, share screens, replace phones and use different email addresses. Graph links can outlive the observation that created them. A system that never expires a relationship may preserve a neat history while accumulating false connections. Record when a link was observed and what would invalidate it.

• WebKit: tracking prevention
• IAB Tech Lab: identifier provenance

A missing ID is information about the system

An unavailable advertising ID does not mean there is no device, no customer or no commercial value. It means that this identification route is unavailable in the present circumstances. An all-zero return must not become a shared audience key that joins everyone who declined tracking.

On Apple platforms, App Tracking Transparency concerns the defined tracking activity as well as access to IDFA. Substituting an email hash or another identifier does not create an exemption. Apple also prohibits deriving a unique device identity from device signals for this purpose. Platform permission and the applicable legal basis are separate questions.

• Apple: tracking permission and identifiers
• Google Play: advertising ID

A distinctive pattern is still evidence to evaluate

Fingerprinting combines observable characteristics such as browser settings, network information or rendering behaviour. A combination can help correlate activity even without a stored cookie. It can also collide across devices or change on the same device. Distinctiveness within one sample does not establish reliable recognition across the entire internet.

IP-based household inference has similar limits. Shared networks, mobile connections, relays and changing addresses affect the association. A model’s confidence score describes its inference under its assumptions. It does not turn a network into a verified household or establish who watched a shared television.

• W3C: fingerprinting guidance
• IAB Tech Lab: CTV programmatic guide

Choose the decision you actually need

Contextual advertising selects against the current page, programme, query or placement. A publisher audience uses the publisher’s available relationship and segment definition. Aggregate measurement describes groups or totals. On-device methods move some processing into a controlled device environment. These approaches solve different problems and expose different information.

Contextual selection can operate without a cross-site person history, while its surrounding delivery and measurement may still process identifiers. A cohort may be broad, or it may be combined with other identifying data. “Cookieless” tells us which storage mechanism is absent. It says little about whether people can still be recognised.

• IAB Tech Lab: OpenRTB 2.6
• Apple: AdAttributionKit
• OAIC: de-identification

Separate an announced replacement from a working product

As checked on 7 October 2026, Google’s October 2025 announcement and August 2026 status page place Topics, Protected Audience and Attribution Reporting on a phaseout or deprecation path. The status page also distinguishes technologies that continue to be supported. This is not evidence that every browser version has already removed every affected API.

There is no single replacement that preserves every cookie-era use case. Evaluate the actual browser or operating-system version, permissions, supported partners and output. A historical architecture diagram can explain an idea perfectly and still be an unsuitable implementation plan today.

• Google: Privacy Sandbox plans
• Google: Privacy Sandbox status

Start with current Australian law

The current Privacy Act concerns information or opinions about an identified or reasonably identifiable individual. An opinion can be wrong and still qualify. The information need not be written down. Both elements matter: what the information is about, and whether the person is identified or reasonably identifiable.

OAIC guidance explains that a name is unnecessary and realistic links with other available information matter. Assess the recipient’s access, resources and practical ability to connect records. A remote theoretical possibility is different from an available customer-table lookup. One event may be enough; a long history is not required.

• Privacy Act: current definition and APPs
• OAIC: what is personal information?

Use my single-out screen to ask better questions

My practical screen asks whether the system knows an identity, recognises someone without a name, or can reasonably connect the record to them. A yes is a reason to apply the statutory test carefully. This is an explanatory framework, not a replacement definition of personal information.

A barista can recognise a regular’s usual order without knowing their name. Advertising systems can also recognise records without names, although a device match does not establish a person. Persistence and the ability to act on a record can strengthen the evidence. Neither is a mandatory legal condition.

• OAIC: what is personal information?

Examine the record after it is combined

A token shared by a group can arrive beside a client ID, timestamp and page URL. The combined record may identify someone even though the grouped token remains non-unique. Equally, two values sitting in browser storage do not prove they travelled together. Inspect the payload, headers, connection and recipient.

Pseudonyms replace an obvious identity with another label. Hashing transforms a value but may preserve matching. Encryption protects content from parties without the means to decrypt it. Aggregation combines observations but can still expose small groups or permit linkage. None automatically establishes de-identification. OAIC assesses that outcome in its actual data-access context, including safeguards and realistic re-identification.

• OAIC: tracking pixels and privacy obligations
• OAIC: de-identification
• Google: enhanced-conversion normalisation

Check sensitivity and coverage

Sensitive information receives additional protection. Examples include health information and qualifying information or opinions about political views, religious beliefs or sexual orientation. A browsing signal’s meaning matters: the assessment concerns what the record reveals about an individual, not merely whether the event was labelled “PageView”.

Then establish whether the organisation and activity fall within the applicable rules. The federal Act covers Australian Government agencies and many organisations, with exemptions and exceptions. Small-business status alone does not settle coverage: health services and some trading in personal information are among the relevant exceptions.

• Privacy Act: current definition and APPs
• OAIC: tracking pixels and privacy obligations
• OAIC: small-business coverage and exceptions

Connect the mechanism to current obligations

For covered organisations, current APP 3 requires solicited collection to be reasonably necessary for the organisation’s functions or activities, using lawful and fair means. Additional consent requirements apply to sensitive information unless an exception applies. APP 4 deals with unsolicited information. APP 5 concerns notification; APP 6 governs use and disclosure. Consent does not automatically resolve every obligation.

APP 7 sets direct-marketing conditions, including opt-out requirements and consent for sensitive-information marketing. APP 8 addresses overseas disclosure. APPs 10 and 11 concern quality, security and disposal when information is no longer needed, subject to exceptions. APPs 12 and 13 address access and correction. Email and SMS can also fall under the Spam Act; the applicable regime depends on the activity.

• OAIC: the current Australian Privacy Principles
• OAIC: direct marketing

Keep the 2026 proposals visibly separate

The exposure draft released on 31 August 2026 remains a proposal in the official consultation material checked on 7 October. It proposes “relates to” wording, express recognition and singling-out examples, and reasonably available linkage. These are proposed statutory changes, not the wording currently in force.

Its proposed APP 3 concerns fair, reasonable and lawful handling; proposed APP 4 addresses sensitive collection and consent to trade, with exceptions. Proposed APP 14 erasure is scoped to qualifying large digital platforms. The obligation diagrams show selected draft provisions. Their numbering and scope must not be substituted for the current APPs.

• AGD: privacy-reform consultation
• AGD: 2026 exposure-draft Bill
• AGD: consultation paper

Start with one real decision

Choose a concrete purpose: exclude recent buyers, measure completed sales, limit repeated TV adverts or personalise a signed-in experience. Identify which record the system needs to recognise and why. “Improve marketing” is too broad to explain a data flow or judge whether each field is necessary.

Include direct customer channels alongside paid media. Email addresses and telephone numbers can be contact destinations as well as matching inputs. Push tokens identify an app delivery endpoint rather than a verified person. A CRM customer key may connect these records, but permission to send one type of message should not be assumed to authorise every audience upload or downstream use.

• OAIC: direct marketing
• Apple: app-specific push tokens
• Google Ads: Customer Match

Record the identifier and its lifecycle

For each identifier, capture its issuer, referent, scope, collection route and storage. Then record recipients, joins, uses, permissions, expiry, reset and deletion behaviour. Distinguish the stored value from the field carrying it and the profile it can reach. Add an owner and a review date.

The downloadable register contains four completed synthetic examples. Its values, retention periods and operating choices are fictional teaching assumptions, not validated deployments or recommended platform settings. Replace them with observed evidence. Record browser expiry, internal retention and recipient retention separately, including anything the recipient has not established.

Walk the request all the way through

Inspect the configured tag or SDK, permitted storage and actual outgoing request. If a server sits in the middle, inspect what it receives, removes, enriches and forwards. Browser developer tools cannot reveal every later server-to-server disclosure. Use server logs, configuration, recipient documentation and contractual evidence to complete that part of the map.

Test relevant states: before a choice, after permission, after refusal, after withdrawal and after logout or reset. Compare expected behaviour with observed behaviour. Keep dated, sanitised evidence; a debugging export can itself contain personal information. A successful HTTP response proves receipt at one endpoint, not every claimed downstream use.

• Google: server-side tagging
• Google: consent mode
• OAIC: tracking pixels and privacy obligations

Use questions that produce inspectable answers

The following walkthrough is fictional. It shows the difference between recording a product label and recording a mechanism. Each answer should point to a capture, configuration or provider statement that another reviewer can inspect.

Close the loop with a decision and an owner

Assess the combined information in each recipient’s context, then document the applicable handling decision. Keep current legal obligations separate from proposed changes. Assign unresolved vendor questions to a named owner rather than converting “unknown” into “anonymous”. Remove fields or joins that have no justified role in the intended decision.

Review the map when a tag template, SDK, consent setup, account-linking rule, provider contract or destination changes. Re-test retention and deletion paths as well as collection. The valuable output is a maintained explanation of what the organisation actually does, with evidence supporting both its capability and its limits.

• OAIC: what is personal information?
• OAIC: de-identification
• Privacy Act: current definition and APPs