Most Adobe Analytics rollouts stop at power users. The Lighthouse Framework is what comes after | Community
Skip to main content
kandersen-1
Community Advisor
Community Advisor
May 13, 2026
Pinned

Most Adobe Analytics rollouts stop at power users. The Lighthouse Framework is what comes after

  • May 13, 2026
  • 6 replies
  • 369 views

I spoke at the Adobe Summit Experience League Theater AMA series a few weeks ago. For anyone who missed it - or who's been wrestling with the same adoption challenges I keep seeing - here's what I covered.

 

The Adoption Ceiling

Most Adobe Analytics and CJA implementations eventually hit the same wall. Power users are thriving. Everyone else is frustrated. They don't understand what the dimensions mean, or why some of them have no data. They've stopped trusting the numbers. And whenever they need something, they file a ticket with IT - where it joins a queue.

CJA makes this worse before it makes it better. More data sources means more dimensions spanning multiple departments, and most people have no map for any of it.

 

The Lighthouse Framework

At Accrease, we've built an approach around this called the Lighthouse Framework. The idea is simple: instead of routing everything to IT, every business unit gets one trusted point of guidance - a 'lighthouse' - who sits in their team, understands their data, and can answer questions or escalate when needed.

Lighthouses are trained across three layers:

  • Basic users learn how data views or report suites are structured for their department specifically.
  • Intermediate users understand how data connects and flows across departments.
  • Lighthouses (super users) learn everything - including how to translate a business requirement into a technical one, and when to handle something in the data view themselves versus when to involve IT.

A few things that have stuck with me across hundreds of implementations:

  • Seats don't measure adoption. Whether people are actually using insights correctly does. Access without onboarding is just noise.
  • Ownership boundaries matter. IT owns the data layer and the CJA connection. Business users own data view structure and naming. When those lines are clear, the whole system runs more smoothly.
  • Formal selection beats volunteers. Domain experts appointed by leadership consistently outperform self-selected ones. The formal selection builds ownership and ensures they have real depth in the data their department produces.
  • Generic training won't carry you. Experience League is great as a supplement. But it won't explain your specific dimensions. Custom onboarding that walks people through your actual setup is what builds real confidence.

 

Where to start

If you don't know where to begin: identify one person in each department who genuinely understands what data that department generates. Create a shared space for them - Teams, Slack, whatever you use - and start a conversation. That's the seed of a lighthouse program.

 

Have you built something like this in your org, or are you still working through the adoption challenge? Would love to hear what's worked - and what hasn't.

6 replies

Jacinda E
Community Manager
Community Manager
May 13, 2026

@kandersen-1 - Your point about formal selection vs. volunteers really resonated with me. 🌟

I’m curious how you approach making the case to leadership that it’s worth the time investment to appoint someone as a Lighthouse, especially when that person already has a full day job? Do you have any advice when it comes to showing value and getting leadership buy-in?

kandersen-1
Community Advisor
Community Advisor
May 15, 2026

Great question - and it's probably the most common pushback I hear too.

 

The framing that tends to land with leadership is this: the time is already being spent, it's just being spent badly.

Every ticket filed with IT represents two people's time - the person waiting (often days) and IT processing something that rarely requires their level of expertise.

 

A Lighthouse doesn't add time to the org, it redistributes it more efficiently. And in most cases, a functioning Lighthouse role settles into 1–2 hours a week once the initial onboarding is done.

 

The second thing that helps: position it as a role upgrade, not an add-on.

Domain experts who become Lighthouses gain visibility, develop a cross-functional skill set, and become the go-to person in their department for data decisions. That's something leadership can sell internally - and it's usually something the person actually wants.

 

When I've helped clients build the business case, I ask them to track just two things for 30 days before the conversation: how many questions went to IT that came from one department, and how long did it take to resolve them. The numbers usually speak for themselves.

Level 2
June 11, 2026

Got it — short version:

Really strong framework, and it matches what we’ve seen in Adobe Analytics/CJA too. The adoption issue usually isn’t tooling, it’s translation.

What works well in practice:

  • Embed “data translators” inside each business unit instead of relying on IT
  • Keep clear ownership (IT = data layer, business = interpretation and naming)
  • Pick lighthouses for influence and communication, not just technical depth
  • Replace one-time training with small, ongoing enablement loops

Biggest challenge is always sustainability. The lighthouses that stick with it are the ones who can visibly reduce friction in their teams (fewer tickets, faster answers, better trust in reports).

Curious what you’ve found works best to keep them engaged after the initial rollout.

uni-adam
Level 2
June 26, 2026

I sit next to the AEM devs who use this: https://developer.chrome.com/docs/lighthouse/performance/performance-scoring which may make your naming quite confusing.

Traditionally these lighthouses were called “Champions” where I’m from.

I think if the Platform Owner of AA/CJA or equivalent “Champions” can run very simple “lab” like hands-on session that show a how-to for a piece of data or web page element etc that could be used in their day-to-day (that there isn’t a dashboard for already) it resonates and then subsequent invites to amplify this hands-on, then the person gains a “skill” and can be a further evagelist.

Level 2
July 6, 2026

This is a great perspective. One point that really stands out is that user adoption is more important than license adoption. Many organizations invest heavily in analytics platforms, but without role-specific onboarding and clear ownership, business users often lose confidence in the data and fall back on IT for every request.

I also like the idea of having department champions who understand both the business context and the data. That approach not only reduces support bottlenecks but also encourages better collaboration between technical and business teams.

Have you found that organizations with a Lighthouse-style model also see improvements in data governance and metric consistency over time? It would be interesting to hear how you measure the success of the program beyond platform usage.

kandersen-1
Community Advisor
Community Advisor
July 7, 2026

You have such a good point with the heavy investment in platform, but if no clear ownership is defined it most often results in no trust in data. Actually did a linkedin post on the topic a week ago.

 

To your question about governance and metric consistency. As part of rolling out the framework it is important to establish who owns what - business vs. IT. (And by business I refer to the lighthouses).

Most organisations where we rolled this out, IT was the main owner. E.g. If business needed a workspace/dashboard it was a support ticket to IT. Problem is that IT often don’t have enough business insights to deliver a proper workspace - at least in most cases you end up with dimensions and metrics with naming conventions that makes sense for IT but no one on the business side. And even more frustrating is that your request end up in a ticket queue, because IT don’t have the ressources to fully support the requests that comes in.

As soon as you define the split - and it of course requires that everyone buys into it - you can start setting requirements towards each other. The most common split we see is that IT becomes responsible for the data foundation and the data quality. Business/lighthouses owns what dimensions and metrics are relevant and the naming convention. As soon as this happens, you experience a different trust in data - business can (in most cases) for the first time fully explain what a dimension represents and if they feel data doesn’t look right, they go to IT who can investigate what’s wrong or document why it is correct.

Obviously its a process and the critical piece is that everyone gets into the same room and sign off on the ownership and split between departments.