Beyond Web SDK: How “dogfooding” Adobe Experience Platform limitations unlocks custom architecture

In the enterprise martech stack, a product’s out-of-the-box functionality is often treated as a ceiling. When a platform like Adobe Experience Platform (AEP) hits a native constraint — such as a limit on direct data mapping — most teams see a roadblock. Every martech investment comes with inherent limitations, but they don't have to define your outcomes.

For strategizing engineers, these limitations can be the blueprints for something better. By applying the mindset of dogfooding — building, testing and breaking your own solutions in production — we move from being platform users to platform architects. This addresses two critical needs: engineers gain agency to fix things, and marketing leaders understand that their tech stack won’t necessarily limit their growth.

At TELUS Digital, dogfooding is our internal validation engine. It ensures that when we propose a workaround, it isn't just a hack to bypass a bug; it’s a battle-tested architecture designed to turn a platform's inherent forcing functions into a brand’s competitive advantage. Using a critical data-mapping constraint within Adobe Experience Platform as a case study, we’ll explore how to bridge capability gaps and turn a force-function limitation into a scalable, server-side advantage.

What dogfooding means to the martech engineer

Popularized by Microsoft in the 1980s as the practice of a company using its own products — or eating their own dogfood — dogfooding is often thought of as simple internal beta testing. For the martech engineer, however, it is a form of radical empathy — a commitment to navigating the same data latencies, schema rigidities and integration hurdles that clients face in high-stakes environments. By treating our own internal platforms as the primary testing ground for complex workflows, we move beyond theoretical best practices. This hands-on friction allows us to identify where a platform’s standard functionality ends, creating the exact space where custom, high-performance engineering begins.

What are the key limitations in Adobe's Web SDK architecture?

Adobe Experience Platform leads the industry in transforming digital experiences through data manipulation, activation and profile unification — but it too has limitations. One notable constraint exists within Adobe Web SDK, a single, lightweight tag that sends XDM-structured data to Adobe's Edge Network for real-time activation. If you've implemented Web SDK, you've likely encountered a specific XDM limitation: the inability to directly map data collected in Tags to a Profile schema.

Adobe provides a native solution for routing web data to a Profile dataset via datastream configuration. However, this capability is intentionally restricted to a specific set of field group classes — it does not support arbitrary profile schema mapping.

When you configure a datastream to ingest Web SDK data into AEP, the data is initially mapped to an ExperienceEvent schema. From there, only the following shared field groups are dynamically inherited by the Profile schema — and only if they contain populated values:

• Consents and preferences details
• Push notification details (pushNotificationTokens)
• Data capture region (available in both Profile and Event schemas)

What this means in practice

If you need to ingest Profile attributes using custom field groups or standard field groups outside the limited set — like profile person details, profile preferences or loyalty data — the datastream Profile dataset pathway won't work.

For example, you may want to build a prospect audience for same-session personalization, or capture cart abandonment behavior for visitors who aren't yet in your CRM. Both require enriching the profile with attributes that fall outside the consent/push token field groups Adobe supports natively. For these cases, you'll need an alternative ingestion method.

Why do these limitations exist?

This constraint is by design. Adobe reserves the datastream Profile dataset for time-sensitive, Edge-enforceable data such as consent, push tokens and regional compliance. General profile attributes require more robust server-side ingestion workflows that can handle richer data models and validation logic.

Solving for the limitations of Adobe's Web SDK architecture

As exemplified in the workflow diagram below, we can implement a server-side ingestion pattern that bypasses datastream Profile dataset limitations while maintaining full schema flexibility. The pattern leverages Web SDK for client-side event capture, event forwarding as the server-side orchestration layer and Adobe's HTTP API streaming endpoint for Profile dataset ingestion. Profile attributes are transmitted server-side using the Adobe Cloud Connector extension within AEP's data collection infrastructure, enabling programmatic control over field group mappings and identity resolution logic.

At this stage, it's reasonable to question whether event forwarding is intended solely for routing data to third-party, non-Adobe destinations. While the majority of Adobe's documentation emphasizes this use case, there is no explicit restriction preventing the forwarding of event data to Adobe applications. This is especially true when pairing the Adobe Cloud Connector with the HTTP API Source Connector to ingest data back into AEP, as the technology emphasizes the agnostic framework. According to Adobe, when using the HTTP API destination connector, you can ingest data from a variety of sources, such as Adobe applications, cloud-based storage, databases and many others.

Although this solution may solve the need to access profile attribute data in real-time (or close to real-time), you still need to ensure that you're not exceeding your contractual obligations to avoid any cost implications. As a best practice, monitor your event forwarding outgoing quota regularly to ensure you remain within your contractual server call entitlements and avoid unexpected overage charges.

From workaround to win: Driving real-time revenue

When an anonymous prospect abandons a cart or engages with a high-intent product page, the window to influence their journey is measured in milliseconds. By engineering a server-side solution to bypass native AEP mapping delays, we are enabling the kind of real-time personalization that is otherwise impossible within standard platform constraints.

For enterprises, this means the difference between a generic follow-up email sent hours later and a dynamic, personalized onsite offer triggered the moment intent is shown. By taking control of the data architecture, we ensure that prospect audiences are populated and activated instantly, transforming a technical forcing function into a direct engine for conversion and customer retention.

Engineering the future

The Web SDK profile dataset limitation isn't a flaw — it's a forcing function. It challenges us to move beyond convenience and build architectures that are more intentional, more resilient and ultimately more aligned with how enterprise data should flow.

By routing profile attributes through event forwarding and the HTTP API, we're gaining server-side control, decoupling ingestion logic from the client and creating a pattern that scales across use cases Adobe may never have anticipated.

This is dogfooding in action: taking the tools we're given, testing their boundaries and proving that engineering dictates outcomes. The best martech solutions are built by engineers who see a gap and ask, "What if we just connected the pieces differently?"

So the next time you hit a wall in AEP, Web SDK or any part of your stack — pause. Reframe the limitation. Then build the workaround that becomes your competitive advantage. Because in martech, the real innovation happens in the margins between what's supported and what's possible.

Reach out to one of our experts today. You can also find our experts at Adobe Summit 2026, where we’ll be presenting live demos with the latest Adobe solutions and AI tooling.