Compliance for Audiences
What you are responsible for before sharing an audience with an advertising platform - BAAs, hashing, audience naming, consent, and exactly what leaves Ours Privacy.
Use this page before you send an audience to an advertising platform. It covers what Ours Privacy does on your behalf, what it deliberately does not do, and what remains your decision.
This page describes product behavior and the terms you accept in the product. It is not legal advice, and your own counsel is the right party to tell you whether a particular audience may be shared.
The four things to know
These are the points you confirm in the product before an audience can sync, restated here so you can read them without a dialog in the way.
Advertising platforms are not HIPAA business associates. Vibe, Meta, and Google do not sign business associate agreements, and their terms prohibit uploading protected health information or consumer health data. A platform that will not sign a BAA is, under HHS guidance on tracking technologies, a party that may only receive de-identified data.
Hashing an email does not make it anonymous. The platform matches the hash back to a person, and that matching is the entire purpose of the upload. Treating SHA-256 as a safeguard is a specific and expensive mistake: the FTC has charged companies on the basis that hashed identifier uploads were disclosures of the underlying identity.
The destination name travels with the audience. Meta prohibits audience names that reflect or imply health information, and the name is displayed verbatim in the platform's interface. Ours Privacy enforces this in code rather than in prose. See Health context in audience names.
You are responsible for having a lawful basis. That includes any consent your visitors must give before you share them with a platform. Ours Privacy automatically excludes visitors who rejected the advertising consent category, but that exclusion is a floor rather than a substitute: visitors with no consent record at all are still sent, so if you need affirmative opt-in you must require it in the audience itself.
The data-sharing acknowledgement
Before an audience can sync anywhere, someone on your account accepts data-sharing terms covering the four points above, and confirms that they have the authority and a lawful basis to share the audience with the selected platforms and that the audience does not contain protected health information or consumer health data.
The acceptance is recorded on the audience with who accepted it, when, and which version of the terms they saw. The Sync to Destinations card shows the date it was accepted.
Two behaviors worth knowing. The version is stored rather than a plain yes, so an acceptance of one version of the terms is never later presented as acceptance of a different one. And removing the last destination from an audience clears the acknowledgement, so re-enabling a sync later means reading and accepting the terms again rather than inheriting a decision somebody made months ago.
The advertising consent gate
Every audience sync excludes visitors who rejected the advertising consent category. You do not configure this and cannot turn it off, and it applies to every Audience Destination.
Three details about how it behaves.
It excludes rejections, not absences. A visitor who was shown a consent banner and rejected advertising is excluded. A visitor who has no consent record, because they were never asked or the banner did not load, is not a rejection and is still sent. This is deliberate: treating silence as rejection would silently shrink audiences for accounts that do not use a consent banner, and treating it as acceptance is not something Ours Privacy would decide on your behalf either. The gate excludes what it can verify.
If you need affirmative opt-in, require it in the audience. Add a visitor condition that Accepted Consent Categories contains advertising. That matches only visitors who actively accepted, which is stricter than the gate and is the right setting when your obligation is opt-in rather than opt-out. See Visitor conditions.
CSV exports are not gated. A download you request is data about your own visitors, and you may need the complete set for reasons unrelated to advertising. If you are downloading a CSV in order to upload it to an ad platform by hand, you are doing what a sync does without the gate, so add the consent condition to the audience yourself.
What actually leaves Ours Privacy
For a sync, two things: the audience's Export Name, and one hashed email address per member. The address is hashed with SHA-256 in the form the receiving platform specifies. Nothing else goes: not names, not phone numbers, not addresses, not your conditions, not your internal audience name, not counts.
For a CSV export, what you chose. The all-fields format contains raw visitor values and is for internal use. The Google and Meta formats contain up to six and ten columns respectively, hashed to each platform's specification. You control where that file goes, which makes a downloaded CSV the higher-risk artifact of the two. See Exporting a CSV.
Your internal name, your conditions, and every visitor attribute outside the chosen export never leave.
Evidence for a compliance review
If you are the person who has to show an auditor what happened, three things are worth knowing about where the record lives.
The acknowledgement is the receipt for the decision. Who accepted the data-sharing terms, when, and which version they saw is recorded on the audience itself and shown in the Sync to Destinations card. That is the artifact that answers "who authorized sharing this audience."
The audience definition is the record of who was included. Because an audience is a set of conditions rather than a saved list, the conditions are the documentation of the population. Keeping the internal Name descriptive is what makes that legible six months later.
Wider organizational activity has its own tools. For periodic access and configuration review across your account, see Audit Log. For what is being forwarded to which third parties across the platform, see Compliance Report and Consent Analytics.
Audience size and re-identification
Platform minimums exist partly for privacy reasons: a very small audience makes the people in it easier to single out. Meta's guidance for a customer list is at least 1,000 people, and Google recommends at least 5,000 members for a Customer Match list to have a reasonable chance of serving.
A tiny audience is worth a second look for a reason beyond targeting effectiveness. An audience of eleven people sent to a platform under any name is a much more specific statement about those eleven people than a list of fifty thousand.
Practices worth adopting
Name the audience for your team, not for the platform. Descriptive internal name, meaningless Export Name, every time. See Export names.
Put consent in the audience, not only in the gate. If your compliance position is affirmative opt-in, the gate does not implement it. A condition does.
Decide who may accept the terms. The acknowledgement is a statement about your organization's authority and lawful basis. Accepting the terms and selecting destinations are governed by permissions, so the people who can do it should be the people who can make that statement. Ask your account administrator about access.
Review synced audiences on a schedule. A daily sync keeps running until somebody stops it. An audience built for a campaign that ended six months ago is still being sent.
Treat downloaded CSVs as the loose end. A file on somebody's laptop has left every control the platform gives you. A recent export can be downloaded again from the audience, so re-downloading when you need it is usually better than keeping a copy.
Next Steps
- Health context in audience names for the naming rule and what it blocks.
- Syncing to destinations for the sync setup and what each run sends.
- Audience Destinations for per-platform behavior and minimums.
- Cookie Consent for collecting the consent an audience can then require.
Need help? Contact support@oursprivacy.com.
How is this guide?