Before uploading past buyers to an advertising audience
Verify eligibility, permission and purpose before any upload, not after the audience performs. Google Ads Customer Match policies require first-party data collected directly, set disclosure and permission expectations, and restrict sensitive categories including pharmaceutical categories, so a research-only label does not settle eligibility. Hashing the list does not remove these obligations, and a past purchase does not itself document consent to advertising use. Record each check with its evidence and owner, and do not upload while any row is unresolved.
For: A research-only merchant considering uploading its order history or customer list to an advertising platform's customer-matching feature.
Your order history was created to fulfil purchases. Uploading it to an advertising platform so those people can be matched and targeted is a different purpose applied to the same records. The age of the data does not shrink the question; a three-year-old buyer list carries the same need for justification as yesterday's orders.
Google's Customer Match policies describe the program as built on first-party data the advertiser collected directly, with disclosure and permission expectations attached. They also restrict use in connection with sensitive categories, including pharmaceutical categories. For a research-only merchant, that restriction must be assessed on the actual catalog and the platform's current policy text before any upload is planned, not waved through on the strength of a disclaimer on the storefront.
A research-only label describes intended product use; it does not establish advertising-platform eligibility, and it does not convert regulated-category products into unrestricted ones. Where the category question is unclear, the answer is to pause and resolve it with the platform's policy owner and qualified advice, not to test the upload and see what happens.
Hashing changes the format, not the obligation
Customer-matching features typically process hashed identifiers. That is a transmission safeguard, not a permission. The person remains the subject of the data, the match still links your records to their platform identity, and the resulting audience still targets individuals. Do not let the technical step stand in for the permission analysis.
The same point applies to any claim that the platform, not you, performs the matching. You chose the list, initiated the transfer and benefit from the audience. The platform's role in the mechanics does not transfer your responsibility for whether those buyers' information may be used this way.
Record what the destination platform actually does with the upload from its own current documentation: what it retains, what it uses for matching and what controls exist over the resulting audience. A general sense of how the feature works is not evidence about the feature as it operates today.
Match the list to its original collection purpose and choices
For the identifiers proposed for upload, establish what the buyers were told when the information was collected. Find the checkout wording, privacy policy version and any marketing choices that were in force for those orders, not the versions on the site today. If the historical wording did not describe advertising-platform sharing, that gap is a finding, and it cannot be repaired retroactively by editing the current policy.
Check recorded choices. Buyers who declined marketing, or for whom no meaningful choice existed, cannot be swept into the upload by default. Where your records cannot show what a cohort was told or chose, treat that cohort's status as unresolved rather than assuming inclusion is harmless.
Whether the documented purposes, choices and disclosures are legally sufficient for this use in your customers' jurisdictions is a question for qualified privacy review. This decision record assembles what they need: the actual wording versions, the choice records' existence and the proposed use. It does not deliver the legal conclusion.
Record the decision with an owner before any action
The decision to upload, restrict or abandon belongs to a named owner who has seen the whole record: category eligibility under the platform's current policy, the permission evidence for the proposed cohort, the destination's actual data handling and the campaign's intended use. A marketing contractor's enthusiasm and a platform's willingness to accept a file are not authorization.
If the decision proceeds, record the approved cohort definition, the exclusions applied, the platform and feature used, and the campaign purpose, so a later question can be answered from this record rather than reconstructed. If the decision is no, record that too, so the idea is not revived next quarter without the analysis.
If you want a scoped Prism website review of how your public pages describe advertising and data use, bring the relevant policy and checkout URLs with a non-sensitive summary of the proposed arrangement; scope, responsibilities, fees and terms are confirmed before work. Customer lists and identifiers never enter the public inquiry.
Audience-upload decision record
Complete this record before any customer list is uploaded to an advertising platform. An unresolved row blocks the upload. The record supports a documented decision; it does not establish legal permission or platform approval by itself.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Audience-upload decision record. The last column is for temporary notes.
Decision item
Evidence or check required
Why it matters
Your finding
Proposed identifiers and cohort
Evidence or check requiredWhich fields and which buyers are proposed for upload, defined precisely enough to reproduce.
Why it mattersA vague all-customers scope prevents any meaningful permission check.
Destination platform and feature
Evidence or check requiredThe named platform, the specific matching feature and its current documentation for data handling.
Why it mattersConfirms what the upload actually does today rather than what it was once understood to do.
Category eligibility
Evidence or check requiredThe platform's current sensitive-category restrictions assessed against the actual catalog.
Why it mattersResearch-only wording does not resolve restrictions that include pharmaceutical categories.
Collection-time wording
Evidence or check requiredThe checkout and policy versions in force when the proposed cohort's data was collected.
Why it mattersEstablishes what those buyers were told; current policy text cannot fix historical gaps.
Documented choices
Evidence or check requiredRecorded marketing and sharing choices for the cohort, or an honest record that they are unavailable.
Why it mattersUnavailable evidence means the cohort is unresolved, not included by default.
Exclusions applied
Evidence or check requiredBuyers removed for declined choices, unresolved status or category concerns.
Why it mattersDocuments that the uploaded set is narrower than the raw order history.
Campaign purpose
Evidence or check requiredWhat the resulting audience will be used for and who will operate it.
Why it mattersKeeps the use within the authorized purpose rather than drifting with the platform's options.
Decision and owner
Evidence or check requiredUpload, restrict or abandon, with the named owner, date and qualified-review reference where used.
Why it mattersNo upload occurs while eligibility, permission or purpose remains unresolved.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
Google Ads Customer Match policies describe that platform's program; other platforms have their own rules, and platform acceptance of a file is not legal permission.
Hashing and platform-side matching are technical mechanics; they do not remove privacy obligations or convert a past purchase into advertising consent.
This record does not determine legal sufficiency of consent, applicable law or platform eligibility; those belong to qualified review and the platform.
Customer lists, identifiers, account credentials and campaign internals stay out of the worksheet's public copies and the consultation form.
Google Ads: Customer Match policies — checked 2026-10-01. Customer Match requires first-party data with disclosure and permission expectations, and restricts sensitive categories including pharmaceutical categories. Research-only language and hashing do not establish eligibility or permission.
Prism features — checked 2026-09-21. An agreed website review can cover marketing claims, store policies and business disclosures, with informational findings rather than legal opinions or certification.