How do I ensure my auction and ranking decisions with an onsite ad serving platform are compliant with first-party data rules?

To keep auction and ranking decisions compliant when using an onsite ad serving platform, treat first-party data as something you can use, but only within the permissions, purpose, and controls tied to how it was collected and disclosed.

Here’s a practical compliance framework:

1) Define what data is being used

Separate your data into buckets:

• First-party data: data collected directly from your users on your own properties
• Derived data: segments or scores created from first-party data
• Sensitive data: health, precise location, children’s data, financial data, etc.
• Restricted personal data: anything your policy, contracts, or local law treats as limited-use

Know exactly which fields influence:

• auction eligibility
• ad targeting
• ranking
• pacing
• bid modifiers
• frequency capping
• suppression

If a data point can affect ranking, it should be governed like a decisioning input, not just a reporting field.

2) Match data use to your privacy notice and consent

Make sure your privacy notice clearly says:

• what data you collect
• the purposes for which you use it
• whether it is used for ad personalization, measurement, or optimization
• whether partners or vendors receive it

If your jurisdiction requires consent for personalized advertising or profiling:

• do not use the data in auction/ranking until consent is valid
• maintain consent status at the user level
• ensure “no consent” users are excluded from personalization logic

Also confirm your consent signals are actually flowing into the ad serving stack.

3) Use purpose limitation

Only use first-party data for purposes that were disclosed and permitted at collection time.

Examples:

• Allowed if disclosed: using purchase history to rank relevant offers
• Risky unless clearly disclosed: using support chat data to prioritize ads
• Usually not allowed without extra care: using health-related behavior to optimize ad selection

If a dataset was collected for subscription management, billing, or fraud prevention, don’t automatically reuse it for ad ranking.

4) Build a data governance layer for decisioning

Create a policy that labels each field as:

• allowed for auction/ranking
• allowed only for measurement
• prohibited for ads
• requires consent
• requires special handling

Then enforce it technically:

• data catalog with approved use tags
• policy checks before data enters the ad server
• separate pipelines for ads vs non-ads data
• suppression rules for sensitive segments
• logging of which signals were used in each decision

5) Minimize data in the auction

Use the least amount of data needed for the decision.

Good practice:

• use coarse segments instead of raw records
• use recency buckets rather than exact timestamps where possible
• avoid exposing raw identifiers to bidders unless necessary and permitted
• avoid sending sensitive or highly granular attributes into the auction

If you can achieve ranking quality with a simple, approved segment, don’t use more detailed personal data.

6) Check contractual and platform constraints

Your onsite ad server may have rules that are stricter than the law:

• platform terms may limit use of first-party data
• some platforms prohibit certain enrichment or audience combinations
• some partners require notice or opt-out handling
• data processing agreements may restrict onward sharing

Review:

• platform terms
• DSP/SSP contracts
• data processing addenda
• cookie/identity provider rules
• regional ad policies

7) Avoid prohibited discrimination or unfair treatment

Even if data use is lawful, some ranking uses can be problematic if they:

• exclude protected groups
• create disparate impact
• use proxies for sensitive characteristics
• personalize pricing or offer visibility in unfair ways

Be careful with segments inferred from:

• ethnicity
• religion
• health status
• income proxies
• vulnerability signals

Have legal/compliance review for categories used to suppress or elevate ads.

8) Maintain user rights handling

If users can request:

• access
• deletion
• correction
• opt-out of sale/sharing
• opt-out of targeted advertising
• restriction of processing

then your auction/ranking logic must respect those rights.

That means:

• honoring opt-outs in real time or near real time
• deleting or suppressing profiles when required
• not re-creating deleted profiles from backups or other systems
• propagating preference changes across vendors

9) Keep auditability

You should be able to answer:

• what data was used?
• why was this ad ranked higher?
• under what legal basis?
• was consent present?
• was the user opted out?
• which vendor received the data?

Keep:

• decision logs
• segment definitions
• consent records
• policy versions
• retention schedules
• vendor sharing logs

10) Test before launch and continuously

Run compliance checks in QA and production:

• verify consent gating
• test opt-out behavior
• test deletion propagation
• test sensitive segment exclusion
• monitor for unauthorized data fields entering the auction
• review ranking changes when new segments are added

A good rule: no production model or rule should use a new first-party field until privacy review approves it.

---

Simple checklist

Before using first-party data in auction/ranking, confirm:

• The data was collected with proper notice
• The intended use was disclosed
• Consent/opt-out status is honored
• Sensitive data is excluded or specially approved
• Only necessary fields are used
• Contracts and platform terms allow it
• User rights requests propagate to the ad stack
• Logs show what drove the decision
• Legal/privacy review approved the setup

---

Best practice

Create a decisioning policy matrix that maps:

• data type
• allowed ad use
• legal basis
• consent requirement
• retention period
• vendor sharing permission
• approval owner

That becomes your operational guardrail for every auction or ranking rule.

If you want, I can turn this into a one-page compliance checklist or a policy matrix template you can use internally.