Imagine a spreadsheet with two rows called “Autumn acquisition”. One is a renamed ChatGPT campaign, the other is a separate campaign created for a different test. A name-based lookup assigns both the same owner and merges their results. The report looks orderly, but its campaign history is wrong.
This is a data-joining problem. Advertisers exporting ChatGPT campaign results need an identity that survives naming changes and distinguishes similar labels. OpenAI’s reporting examples include campaign IDs as well as campaign names. Keep both: the ID identifies the record and the name helps a person recognize it. OpenAI’s campaign-management guidance recommends durable ID-based lookup because names can return several matches.
The table you need before the dashboard
Create a campaign register with one row per campaign identity. Include account ID, campaign ID, current name, internal owner and the date the record was last checked. If campaigns from several client accounts share a reporting file, use account ID together with campaign ID as your join key. This is a conservative internal convention that avoids relying on assumptions about identifier uniqueness across accounts.
Keep performance observations in a separate table. A daily observation needs its campaign key, reporting date and the dimensions that make the row unique. Country-level rows, for example, cannot be treated as if the only key were campaign and date. Otherwise a join or deduplication step can collapse legitimate observations.
Write the grain above each table in plain language. “One campaign on one reporting day” is a grain. “One campaign, country and reporting day” is another. This sentence should be clear before anyone writes a lookup formula or database query.
A rename should change a label, not history
Consider a hypothetical campaign with ID cmp-example-17. It is called “September lead test” on Monday and “Qualified lead test” on Wednesday. The delivery from both days belongs to the same campaign identity. Joining by the current name can strand Monday’s data or incorrectly split the campaign into two histories.
A simple register may keep only the current label while preserving the ID. If you need to show what the name was when a decision occurred, maintain a separate name history with effective dates. Do not add historical names as extra rows in the main one-row-per-campaign register unless your join deliberately handles that history.
The dangerous pattern is a one-to-many join that quietly multiplies spend. If three historical names match one campaign ID, every performance row may appear three times. The arithmetic can still look plausible when the dashboard is heavily summarized. Check row counts and spend totals before and after the join.
Run three integrity checks
First, check uniqueness in the register. No two active register rows should share the chosen identity key unless the design explicitly includes another dimension. When duplicates exist, resolve the record model rather than keeping whichever row the spreadsheet returns first.
Second, count unmatched performance rows. A campaign missing from the register should appear in an exception view, not disappear from the financial total. A newly created ChatGPT campaign may simply need to be added to the register. Dropping it from the report would understate spend and hide the operational gap.
Third, reconcile totals before and after enrichment. If adding owners and readable labels changes total spend or clicks, the join probably duplicated or removed records. The enrichment should add descriptive information without changing the measures. Document any intentional filtering as a separate step.
A rename, the same campaign
- ID and account
Join results using verified identity, not similar names.
- Descriptive register
One active register row per key prevents historical names multiplying spend.
- Control total
Spend and clicks should remain unchanged after adding an owner.
Handle agency reporting deliberately
For an agency, client separation belongs in the data model as well as in folder names. A file called “Client A weekly report” does not prove that every row belongs to Client A. Filter using the verified account identifier and check the unique account IDs present before preparing a client-facing export.
Avoid copying a previous client’s register and editing only the visible name column. Old campaign IDs, owners or destination links can remain behind the presentation layer. Build the report from an explicit account selection, then inspect the resulting scope. This is an internal QA recommendation, not a statement about AthillyAds access controls.
Keep business labels such as service line or campaign purpose in the register, with a named person responsible for changes. The platform name can change for operational reasons. Your internal classification should change only when the underlying business meaning changes.
A safe handover artifact
Give the next analyst the register, grain definition, identity fields and a short list of integrity checks. Include an example of a renamed campaign and an unmatched row. Those examples explain the model more effectively than a screenshot of a finished dashboard.
When exporting from ChatGPT reporting, retain available identifiers even if the client-facing version hides them. They make later reconciliation possible. Reporting data lineage extends this practice from campaign identity to the full report pipeline, while multi-client report QA covers scope checks before delivery.
The official reporting context and campaign-ID fields appear in OpenAI reporting. The register and validation procedures here are independent operational recommendations; they do not imply a built-in campaign register or automated join validator in AthillyAds.
Sources and scope
Preserving campaign identity through renames and preventing duplicated measures when enriching exports.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.