What’s the hardest part about running experiments in Adobe Target?

[kandersen]

In my experience, the hardest part of experimentation often isn’t the tool itself – Adobe Target is powerful and flexible – but the context it lives in.

For some organizations, the blocker is the data foundation: experiments become guesswork if the right data streams aren’t stitched together, or if audiences aren’t well-defined.

For others, it’s the organization: running tests is easy, but aligning teams, stakeholders, and processes around experimentation can be painfully slow. I’ve seen companies where the bottleneck wasn’t in setting up a Target activity, but in getting approval to launch it.

👉 I’m curious: what’s the toughest challenge you’re facing right now when it comes to running experiments in Adobe Target?

• Is it data (getting the right foundation in place)?

• Is it organizational (building trust and speed in decision-making)?

• Or is it something entirely different?

Would love to hear how you’re tackling it — and maybe we can all steal a few ideas from each other 🙂 

😉

[kandersen]

When it comes to running experiments in Adobe Target, what slows you down the most?

A) Data foundation — stitching the right signals and audiences together
B) Organization — approvals, politics, and decision-making
C) Something else entirely (tell me what!)

Drop your vote (and share a war story if you’ve got one!). Curious to see which pain point wins…

[Gokul_Agiwal]

Hey @kandersen  

Totally agree with your point — the tool is often the least of our problems.

In my case, currently the biggest challenge for me is that managing stakeholder expectations, especially around what Adobe Target’s Visual Experience Composer (VEC) can realistically do.

There’s often an assumption from business teams that “anything is possible” with Target, and that personalization should be quick and easy without deep technical involvement. But in reality, meaningful and scalable personalization often requires coordination with developers, a strong data layer, and a clear understanding of the underlying site architecture.

Many stakeholders aren’t aware of the limitations of VEC, especially when dealing with SPAs, dynamic content, or tag-based rendering. As a result, there’s a gap between what’s requested and what’s feasible — which leads to frustration on both sides.

We're working on this by educating them, setting clear boundaries and pushing towards more tech support but yes it's a process. 

[kandersen]

Thanks for sharing, @Gokul_Agiwal!

I’ve seeing something similar regarding the VEC when it comes to SPA, but it's been more in regards to confusion on how Views are working and when to use which view. That misunderstanding often leads to the same frustration you describe: expectations from business that “it should just work,” while in reality the underlying implementation is much more nuanced.

I really like how you framed it: it’s less about the tool and more about expectations vs. feasibility. One thing I’ve sometimes done is create a quick side-by-side list of their most common use cases and when the VEC can be used vs. where it clearly needs developer involvement.

Curious — in your experience, what tends to work best when educating stakeholders? Do you lean more on demos, documentation, or just repeated conversations until it sticks?