ePrivacy decides whether advertising technology may store or read information on a device. The DSA separately governs how online platforms identify ads, disclose who is behind them and why a recipient saw them, and restrict certain profiling-based ads.
The comparison uses the ePrivacy Directive, EDPB tracking and consent guidance, and Regulation (EU) 2022/2065, including DSA Articles 26, 28, and 39.
Cookie consent does not satisfy the DSA's advertising rules, and a DSA ad label does not authorize tracking. ePrivacy Article 5(3) governs storing information on, or gaining access to information already stored in, terminal equipment. DSA Article 26 applies when an presents ads on its interface and requires real-time identification of the ad, the person on whose behalf it appears, the payer when different, and meaningful information about the main targeting parameters. Separate DSA rules prohibit certain profiling-based ads and require ad repositories for very large online platforms and very large online search engines.
Side-by-side comparison
ePrivacy cookie consent vs DSA ads obligations
Use these rows to keep terminal-equipment consent, online-platform ad transparency, profiling restrictions, and VLOP/VLOSE repository evidence distinct.
Decides whether advertising, analytics, or measurement technology stores information on, or gains access to information already stored in, terminal equipment, and whether consent or a narrow Article 5(3) exemption supports that operation.
Second framework
DSA ads workstream
Directly applicable rules for ads presented by online platforms, including real-time disclosures, specified profiling restrictions, and an additional repository duty for VLOPs and VLOSEs.
Storage of information on terminal equipment or access to information already stored there, including non-cookie tracking techniques when the Article 5(3) criteria are met.
Article 26 applies when a covered presents advertisements on its online interface. Article 19 generally excludes providers that qualify as micro or small enterprises unless they are designated VLOPs. A covered platform must provide the required ad, beneficiary, payer, and targeting information for each ad in real time.
Run both scope tests. Article 5(3) can apply to the tracking technology regardless of whether the service is an ; Article 26 depends on the provider and ad-presentation context.
If consent is required, it must meet GDPR-standard consent quality: freely given, specific, informed, unambiguous, affirmative, demonstrable, and withdrawable as easily as it was given.
The Article 26 duty belongs to the provider of the that presents the ad. Advertisers and payers supply facts the platform needs, but the DSA row does not replace their separate GDPR, consumer-law, or ePrivacy duties.
Keep consent buttons, preference centers, and consent logs separate from ad labels, sponsor disclosures, or transparency records, even if they are reviewed in the same launch gate.
Third-party advertising cookies and operational advertising cookies are not within the consent exemptions described by WP29; analytics needs a separate purpose and safeguard assessment.
The DSA trigger is the platform's presentation of an ad, not the use of a cookie. Article 26 requires the ad label, beneficiary, payer when different, and meaningful information about the main parameters used to select the recipient.
Tracker inventory, purpose map, Article 5(3) classification, exemption analysis, consent UX screenshots, CMP settings, consent logs, reject and withdrawal tests, and proof that consent-requiring tools do not fire before consent.
For each ad, show that it is advertising, identify the beneficiary and payer when different, and provide easily accessible targeting information. Also provide a commercial-communication declaration function for recipients who publish content, and enforce the Article 26 and 28 profiling restrictions.
Label shared records with the obligation they support. An ad journey screenshot may help both teams, but it does not supersede consent logs or a DSA citation.
If the ad stack stores or reads terminal-equipment information and no narrow exemption applies, block the tag until consent is obtained and withdrawal is available.
Keep the rendered ad, label, beneficiary, payer, targeting explanation, parameter-change route, commercial-communication declaration, and checks for special-category and minor profiling. VLOPs and VLOSEs also need the Article 39 repository record.
Keep separate sign-offs. The ePrivacy record supports the storage or access decision; the DSA record supports what the platform disclosed, prohibited, and retained.
Set the ePrivacy check before launch, because tags and pixels should not start collecting until the terminal-equipment question and any required consent path have been resolved.
Article 26 information must be available for each ad in real time. A VLOP or VLOSE repository must retain the required record throughout the display period and until one year after the ad was last shown.
Complete ePrivacy controls before consent-requiring technology runs and DSA controls before the platform displays the ad. Build the repository record at delivery time rather than reconstructing it later.
Digital Services Coordinators supervise providers within their Member State competence, while the Commission has exclusive powers for the enhanced obligations that apply only to designated VLOPs and VLOSEs and shares other DSA enforcement responsibilities for those services.
Identify the service category and competent authority before escalating. The national ePrivacy authority and the DSA authority may not be the same body.
Reuse the ad creative, advertiser and payer identities, targeting parameters, delivery period, and reach data for Article 26 and, for VLOPs and VLOSEs, Article 39. The DSA record does not prove valid ePrivacy consent.
Share factual records, but label the legal purpose of each field. Consent state belongs to the ePrivacy decision; ad identity, targeting disclosure, and repository fields belong to the DSA decision.
If an will present the ad, prepare Article 26 disclosures and test the profiling restrictions. If the provider is a VLOP or VLOSE, also prepare the Article 39 repository record.
Neither review substitutes for the other. Do not fire consent-requiring technology without the ePrivacy basis, and do not display the ad until the applicable DSA controls are ready.
Storage of information on terminal equipment or access to information already stored there, including non-cookie tracking techniques when the Article 5(3) criteria are met.
Article 26 applies when a covered presents advertisements on its online interface. Article 19 generally excludes providers that qualify as micro or small enterprises unless they are designated VLOPs. A covered platform must provide the required ad, beneficiary, payer, and targeting information for each ad in real time.
Run both scope tests. Article 5(3) can apply to the tracking technology regardless of whether the service is an ; Article 26 depends on the provider and ad-presentation context.
If consent is required, it must meet GDPR-standard consent quality: freely given, specific, informed, unambiguous, affirmative, demonstrable, and withdrawable as easily as it was given.
The Article 26 duty belongs to the provider of the that presents the ad. Advertisers and payers supply facts the platform needs, but the DSA row does not replace their separate GDPR, consumer-law, or ePrivacy duties.
Keep consent buttons, preference centers, and consent logs separate from ad labels, sponsor disclosures, or transparency records, even if they are reviewed in the same launch gate.
Third-party advertising cookies and operational advertising cookies are not within the consent exemptions described by WP29; analytics needs a separate purpose and safeguard assessment.
The DSA trigger is the platform's presentation of an ad, not the use of a cookie. Article 26 requires the ad label, beneficiary, payer when different, and meaningful information about the main parameters used to select the recipient.
Tracker inventory, purpose map, Article 5(3) classification, exemption analysis, consent UX screenshots, CMP settings, consent logs, reject and withdrawal tests, and proof that consent-requiring tools do not fire before consent.
For each ad, show that it is advertising, identify the beneficiary and payer when different, and provide easily accessible targeting information. Also provide a commercial-communication declaration function for recipients who publish content, and enforce the Article 26 and 28 profiling restrictions.
Label shared records with the obligation they support. An ad journey screenshot may help both teams, but it does not supersede consent logs or a DSA citation.
If the ad stack stores or reads terminal-equipment information and no narrow exemption applies, block the tag until consent is obtained and withdrawal is available.
Keep the rendered ad, label, beneficiary, payer, targeting explanation, parameter-change route, commercial-communication declaration, and checks for special-category and minor profiling. VLOPs and VLOSEs also need the Article 39 repository record.
Keep separate sign-offs. The ePrivacy record supports the storage or access decision; the DSA record supports what the platform disclosed, prohibited, and retained.
Set the ePrivacy check before launch, because tags and pixels should not start collecting until the terminal-equipment question and any required consent path have been resolved.
Article 26 information must be available for each ad in real time. A VLOP or VLOSE repository must retain the required record throughout the display period and until one year after the ad was last shown.
Complete ePrivacy controls before consent-requiring technology runs and DSA controls before the platform displays the ad. Build the repository record at delivery time rather than reconstructing it later.
Digital Services Coordinators supervise providers within their Member State competence, while the Commission has exclusive powers for the enhanced obligations that apply only to designated VLOPs and VLOSEs and shares other DSA enforcement responsibilities for those services.
Identify the service category and competent authority before escalating. The national ePrivacy authority and the DSA authority may not be the same body.
Reuse the ad creative, advertiser and payer identities, targeting parameters, delivery period, and reach data for Article 26 and, for VLOPs and VLOSEs, Article 39. The DSA record does not prove valid ePrivacy consent.
Share factual records, but label the legal purpose of each field. Consent state belongs to the ePrivacy decision; ad identity, targeting disclosure, and repository fields belong to the DSA decision.
If an will present the ad, prepare Article 26 disclosures and test the profiling restrictions. If the provider is a VLOP or VLOSE, also prepare the Article 39 repository record.
Neither review substitutes for the other. Do not fire consent-requiring technology without the ePrivacy basis, and do not display the ad until the applicable DSA controls are ready.
Make the ePrivacy call first when a tracker, tag, or identifier may touch terminal equipment.
When a covered presents the ad, prepare the Article 26 label, beneficiary, payer, and targeting explanation for the individual ad; document any Article 19 micro or small enterprise exclusion.
Block profiling-based ads that use special-category personal data, and apply the separate Article 28 rule when the platform knows with reasonable certainty that the recipient is a minor.
For a VLOP or VLOSE, create the Article 39 repository record and retain it until one year after the ad was last shown.
Reuse delivery facts across the two reviews, but do not treat a consent record as an ad disclosure or an ad disclosure as consent.
For ePrivacy, start with the technical act. The EDPB describes Article 5(3) as applying when operations involve information, qualifying terminal equipment, and either storage or gaining access. A device qualifies as terminal equipment when it is connected or connectable to a public communications network, but the storage or access itself can use other means and can occur while the device is disconnected. That analysis is broader than browser cookies: URL and pixel tracking, local processing, IP-only tracking scenarios, IoT reporting, and unique identifiers can require review.
The ePrivacy decision is therefore not whether an ad is transparent. It is whether the advertising, analytics, measurement, attribution, frequency-capping, anti-fraud, or audience-building setup stores or reads information on terminal equipment, and whether consent or a narrow necessity exemption supports that operation.
Inventory cookies, pixels, SDK calls, local storage, mobile identifiers, hashed identifiers, and server calls that read device-side values.
Classify whether each operation stores information, gains access to stored information, or does both.
Separate strictly necessary service functions from advertising, analytics, profiling, attribution, and measurement purposes.
Record the user-facing purpose, technical mechanism, third parties, retention, consent state, withdrawal path, and source citation.
DSA Article 26 applies to providers of online platforms that present advertisements on their online interfaces, subject to the Article 19 exclusion for providers that qualify as micro or small enterprises and are not designated VLOPs. For each covered ad shown to each recipient, the platform must make clear in real time that it is an ad, on whose behalf it is presented, who paid when that is a different person, and the main parameters used to select the recipient, with information about changing those parameters where applicable.
The DSA also draws narrower lines for profiling. Article 26(3) prohibits online platforms from presenting ads based on profiling that uses GDPR Article 9(1) special categories of personal data. Article 28(2) prohibits an accessible to minors from presenting ads based on profiling using the recipient's personal data when the provider knows with reasonable certainty that the recipient is a minor.
Article 39 adds a repository duty only for very large online platforms and very large online search engines. Their searchable repository must cover the period while the ad is shown and one year after it was last shown, exclude recipients' personal data, and include the ad content, beneficiary, payer when different, display period, targeting or exclusion parameters, and reach information.
Classify the service first: the Article 26 duties concern online platforms, Article 19 excludes qualifying micro and small enterprises unless designated as VLOPs, and the Article 39 repository is limited to designated VLOPs and VLOSEs.
Capture the ad label, beneficiary, payer, targeting explanation, parameter-change route, and the exact ad shown to the recipient.
Test special-category and minor-profiling restrictions before the campaign enters delivery and again when the disclosure is drafted.
Do not treat compliance with Article 26 as proof that a tracker may run. Complete the Article 5(3) consent or exception analysis separately.
When ePrivacy requires consent for advertising or tracking access, the consent record should show more than a banner screenshot. EDPB consent guidance links valid consent to a freely given, specific, informed and unambiguous indication by clear affirmative action, with withdrawal available as easily as consent was given.
The Cookie Banner Taskforce report gives practical risk signals for this evidence review: no default setting of consent-requiring cookies, no pre-ticked boxes, understandable purpose information, reject options that are not hidden or misleading, and accessible withdrawal after consent has been collected.
Keep the consent prompt copy, first-layer and second-layer screenshots, purpose labels, vendor list, consent-string configuration, and timestamped consent logs.
Test accept, reject, granular choice, no-choice, and withdrawal paths before release.
Check whether the banner clearly separates ePrivacy read/write consent from later personal-data processing choices.
Retain proof that consent-requiring cookies, pixels, SDKs, or identifiers do not run before the required positive action.
The WP29 cookie-exemption opinion is especially useful for ad stacks because it warns against treating operational advertising cookies as strictly necessary. It says third-party advertising cookies are not exempt from consent and extends that consent view to operational advertising purposes such as frequency capping, financial logging, ad affiliation, click-fraud detection, research, market analysis, product improvement, and debugging.
Analytics also needs careful classification. The same opinion distinguishes first-party aggregated analytics with safeguards from third-party analytics that tracks users across sites, and says first-party analytics were not within the two Article 5(3) exemptions even if they may present lower privacy risk when safeguarded.
Do not classify an advertising or measurement cookie as strictly necessary merely because the business needs it for monetization or reporting.
Keep a purpose-by-purpose assessment when one tag supports security, measurement, fraud checks, attribution, and targeting.
For analytics, record whether the implementation is first-party or third-party, aggregated or user-level, cross-site or same-site, and whether opt-out and anonymization safeguards exist.
For DSA work, reuse the factual inventory and disclosure screenshots, then add the Article 26 fields and, for VLOPs or VLOSEs, the Article 39 repository fields.
Turn this comparison into a cited advertising launch check
Map cookies, pixels, SDKs, consent UX, ad labels, advertiser and payer fields, targeting explanations, profiling restrictions, and repository records to the rule each item supports.