Identity & Addressability
Part of AdTech data architecture
Planning a stable advertising data identifier
Define stable campaign, platform-object and source-event keys with clear namespaces, dated mappings and validation checks.
A stable advertising data identifier needs a defined subject and scope. An internal campaign reference, a platform line-item ID and an event key identify different things. Plan each key by stating what it identifies, where it must be unique and whether its source can change or reuse it.
Define the entity and namespace
Write a rule such as “This value identifies one business campaign within our organisation”. Or write “This source value identifies one line item within this platform account”. Keep the platform and account or network with a native ID. Then the model will not treat similar values from different sources as the same object.
Display & Video 360 distinguishes its system-assigned lineItemId from displayName and records the parent insertionOrderId. Preserve those IDs as source values. Other source systems may supply their own object identifiers; document those fields against the product that issues them. No external platform defines your organisation’s internal campaign reference.
| Key | Intended subject | Limit |
|---|---|---|
| Business campaign ID | One campaign concept in your records | Does not imply every platform has the same campaign object |
| Native object key | One object in a specified platform and account | Does not match a similar value from another source |
| Source event key | An occurrence or opportunity under the source’s rules | Does not become a universal cross-platform event ID |
Keep changing attributes separate
Where your organisation controls the campaign record, issue a unique ID that is not reused. Store its name, market, dates and owner as attributes. Those details may change without changing the campaign’s identity. The useful properties are uniqueness, persistence and a documented issuing process; the particular character format is secondary.
If a source ID is missing, leave the relationship unresolved until the platform owner can provide it or approve another defensible link. Do not create an ID from a matching name. Keep retired internal IDs in history rather than assigning them to new campaigns.
Keep relationships and event keys in scope
One business campaign can acquire several platform line items. Record the native object, relationship and effective dates separately from the stable campaign ID. Preserve earlier relationships so historical reports remain interpretable.
Event keys require their own source rules. Document the field that carries the event key, the system that issues it and the scope in which it is unique. Do not assume that an identifier issued by one party is the same value seen by another.
An opportunity-level identifier is not proof of a delivered impression. Such keys do not establish a shared buyer, seller and ad-server event ID.
Validate the design
Check uniqueness within each declared namespace, missing IDs, reuse of retired internal IDs and conflicting campaign relationships for the same object and dates. Trace a small set of source objects from native ID to business campaign and back. Keep failed traces as exceptions.
This campaign-key design does not need a person or device identifier. If a proposed use adds linkable audience data, assess that separate data flow with the appropriate privacy owner.
