Back to agent
Constraintconstraint.aep-second-gen-data-access-api-200kb

AEP Second-Generation Data — Non-Ecosystem Export — 200 KB / profile / year

Adobe Experience Platform limits batch export of Second-generation Data via the Data Access API or any non-Destination-SDK means to 200 KB per profile per year — more restrictive than the first-generation 500 KB threshold, effectively closing the agnostic-export path for second-gen profile data and reinforcing the architectural push toward AEP-as-edge-node for composable CDP integrations.

confidence 76%v1reviewed May 10, 2026aep, governance, activation-tax, data-liquidity, vendor-constraint, second-gen, data-access-api

"Customers may batch export an average of up to 200 KB of Second-generation Data per Profile per year through the Data Access API or other means within Adobe Experience Platform Activation" (source.helpx-adobe-com.legal-product-descriptions-aep-activation-2026).

Why this is architecturally significant. The counterintuitive finding: for the agnostic export path (Data Access API, non-AEP-ecosystem), second-generation data is more constrained than first-generation. The 1500 KB second-gen limit (constraint.aep-second-gen-export-1500kb) applies exclusively when routing through AEP's Destination SDK framework — it is an AEP-ecosystem premium, not a general second-gen quota.

The practical implication for composable CDP designs: organizations attempting to use the Data Access API to move second-gen profile attributes to an external CDW (Snowflake, BigQuery, Databricks) for downstream composable activation or analytics are limited to 200 KB per profile per year. A highly engaged customer with a rich second-gen profile — behavioral sequence, AI-derived scores, cross-channel event history — may have hundreds of kilobytes of second-gen attributes. At 200 KB, that budget is consumed quickly.

How it relates to constraint.aep-first-gen-export-500kb. Both constraints use the Data Access API as the export mechanism. First-gen (legacy, generally raw event data) has a 500 KB allocation. Second-gen (current, enriched profile attributes and computed scores) has a 200 KB allocation via the same path. The message from AEP's product architecture is consistent: use Destination SDK for second-gen data, not the Data Access API.

Recommended architectural response. The pattern.aep-as-edge-node pattern (position CDW as the canonical data store, use AEP only for Destination SDK activations) is the direct structural mitigation. Organizations investing heavily in AEP second-gen profile enrichment who also want CDW-native analytics and composable activation should accept the Destination SDK constraint or adopt the edge-node pattern.

Confidence note: Source is a search snippet from the helpx.adobe.com product description page (403-blocked for direct fetch). The source node source.helpx-adobe-com.legal-product-descriptions-aep-activation-2026 was created today from the snippet. Confidence will rise to ≥0.90 when the primary URL becomes accessible. The 200 KB/profile/year claim is internally consistent with the known AEP quota architecture (agnostic export is more restricted than ecosystem export) and was cross-verified against the phrasing of the first-gen and second-gen Destination SDK limits in existing constraint nodes.

Sources

Related

This node →

  • contrasts-withconstraint.aep-second-gen-export-1500kbThe 200 KB Data Access API limit and the 1500 KB Destination SDK limit both apply to Second-generation AEP data — they are complementary constraints on the same data class via different export paths. Surfacing both clarifies that the 1500 KB figure is not a general second-gen limit but an ecosystem-bound one.
  • evidence-forconcept.activation-tax200 KB/profile/year limit for second-gen data via agnostic export path — more restrictive than first-gen — is the sharpest instance of the activation tax: investment in richer second-gen profiles paradoxically tightens the export ceiling.