Summary: This is a practical guide for UX research ops professionals tasked with rolling out Pendo across orgs of any size. It lays out a structured, strategy-first approach that avoids common tagging mistakes and focuses on building the kind of insight that actually drives executive and product decisions.
Pendo is one of those tools that gets purchased for its flashiest feature, usually the in-app messaging system, and then handed off to a product or UX team with a vague hope that someone will "set it up."
What it actually is, though, is a behavioral analytics platform. When configured with intent, it can tell you exactly what users are doing inside your product. It doesn't just track where they go. It helps you understand whether they're completing the workflows your team believes are important. Unlike Google Analytics, which stops at visits and clicks, Pendo lets you define tasks, build tracked userflows, and measure real interaction.
In most orgs, though, Pendo ends up serving one of two roles:
A place where PMs experiment with pop-ups and tooltips
A massive collection of mislabeled tags no one uses or trusts
If you're working in UX research operations, like I am, you've probably seen this pattern before. Your job isn't just to track user behavior in one product. You're responsible for setting up a system that works across multiple applications, with multiple teams, while delivering one clean, consistent dashboard to executive leadership. This work is about structure, strategy, and long-term data clarity. It's not about the excitement of tooltips or how many buttons you've tagged.
In this post, I'll walk you through how I approach Pendo rollouts in large orgs. This isn't the idealized "how it could work" version. It's the version that actually gets dashboards populated, teams aligned, and data ready for real decision-making.
And it starts by avoiding the single most common mistake.
Default Setup
If you've read Pendo's help documentation, attended a training session, or sat through a vendor demo, you've heard some version of this:
“Tag all your features and pages first. You'll figure out how to use the data later.”
That advice can work if you're a two-person team working on a single app. It falls apart the moment you try to scale.
Here's what I see happen almost every time:
One team tags a "Submit" button as
submitButton_v1
Another calls the same type of interaction
btn-submit-primary
A third doesn't tag it at all because they're still deciding which workflows matter
Now imagine trying to build a tracked userflow that compares task completion rates across all three products. Or explaining to leadership why Product A shows a 20 percent drop-off, while Product B shows nothing. The difference isn't in the user experience. It's in the setup.
The underlying issue is the order of operations. Pendo's default onboarding logic treats tagging like a neutral first step, as if analysis always happens after the fact. But in reality, every tag is an assumption. Every inconsistent label weakens your dataset. Every missing step introduces blind spots you won't notice until it's too late to fix easily.
From a UX research ops perspective, you cannot afford to let that happen. You don't start with tagging and hope for insight later. You begin by understanding what matters, and you only tag what supports that understanding.
There's also a deeper pattern at play. Executives tend to want answers to evaluative questions. They care about benchmarks, performance trends, and comparisons across teams. Product teams tend to want generative insight. They want to explore behavior and discover what's not yet obvious. Both needs are valid. But the evaluative layer must come first if you want to establish a shared foundation.
Tracked userflows, or what Pendo calls the "Funnels," give you exactly that. They produce clean, comparative, behavior-based metrics from the start. That data fills the dashboard with something useful. And once that happens, product teams begin to engage with Pendo in a different way. They care more. They ask better questions. They start refining their Funnels and exploring more advanced features, because they have a reason to care.
Auto-Tagging Sucks
Auto-tagging is one of the first things Pendo promotes when you're onboarding. The feature sounds great in theory. It scans your application and automatically identifies clickable UI elements like buttons or links. In a small, simple app, this might save you time. But in real-world setups, especially in large orgs with custom components, nested layouts, and inconsistent UI patterns, I've never seen auto-tagging produce usable data.
Here's what usually happens. Auto-tagging creates a giant pile of elements with vague names like "div1" or "buttonX," applied inconsistently across screens. That data then gets pulled into Funnels, Paths, and dashboards. It gives the illusion that something is being tracked, but the underlying tags are meaningless. People end up interpreting the wrong thing, questioning the tool itself, or rebuilding everything from scratch later.
I now treat this as a UX ops red flag. Auto-tagging might technically work in some environments, but it breaks the moment your app stops being generic. And even when it works, it produces tagging that reflects layout, not intent. As a researcher or research ops pro, that distinction matters.
My advice is simple:
Don't even mention auto-tagging in your internal documentation or kickoff sessions. Instead, assume all tagging will be manual, and set stakeholder expectations accordingly.
It might feel slower at first, but manual tagging forces teams to think clearly about what behaviors actually matter. That clarity is what gives your Funnels meaning.
Start With Strategy
In most implementations I've seen, teams start by opening up Pendo and tagging every clickable element they can find. Pages, buttons, menus, and modals all get tagged. Then they stop and ask, "Now what?"
Tagging everything upfront gives you a list of actions but no clear way to prioritize or connect them to business goals. That becomes a major problem once you try to roll this data into an executive dashboard or use it to influence product decisions. Pendo doesn't fall short. The setup did.
Instead, start with strategic alignment. Before a single tag is applied, schedule conversations with stakeholders at multiple levels:
Step 1: Talk with executive leadership. What kinds of user behavior do they need visibility into? What metrics are already being reported across business units, and which ones are missing? In most cases, they want clarity around task completion, efficiency, adoption trends, or friction points. Their goal is to compare behavior across products in ways that can drive decisions and allocate resources. This is where evaluative data plays the biggest role. It gives them structured benchmarks and helps them track improvement over time.
Step 2: Shift to product-level conversations. PMs and designers are usually more interested in generative insight. They want to know where users are getting stuck, how people move through complex workflows, and what behavior isn't matching expectations. These are exploratory questions, and they matter a lot.
The point is you’ll need to build the evaluative foundation first, or else none of the exploration will have context.
Your job, as a UX research ops pro, is to connect these layers. Think of it as a gap analysis between what executives need to make decisions and what product teams want to discover. The output of that work becomes your tagging playbook. It defines which actions need to be tracked across products, which workflows are worth building Funnels for, and what structure will keep the data usable.
This alignment step also prevents the biggest mistake I see in Pendo rollouts. When every team defines their own tracking approach with no shared structure, the result is fragmented data that cannot scale. The work of research ops is to prevent that from happening and to set up a system where each product's insights feed into a holistic organizational strategy.
Top Task Analysis
Once you've aligned on what outcomes matter across leadership and product, the next step is figuring out exactly what to tag. This is where most teams start pulling up the app and pointing to buttons. But if your goal is structured, comparative data across multiple products, you cannot afford to guess which elements matter. You need to ground the tagging in real user behavior.
I use Top Task Analysis as the first step. It's a practical way to bring structure to a sprawling product and make tagging decisions based on actual user priorities, not opinions.
Here's how I run it:
Ask the product team to list the most common tasks their users perform. You're looking for the top 20 percent of actions that represent 80 percent of usage. Think of things like "run a report" or "submit a request," not individual clicks or screen visits.
Identify any rare but high-impact tasks. These are things users might not do often, but when they do, the experience matters. For example, an "export audit log" task might only happen once a month, but if it fails or takes too long, it can damage trust or create compliance risk.
De-duplicate and refine the list down to 10 to 15 core tasks. If two tasks are very similar, only keep the one that is most complex or most representative of your end users goals. Prioritize tasks that follow different user paths so you cover a wider range of UI elements and interaction patterns. The goal is to avoid overlap and make sure your list represents the full variety of how users actually move through the product.
This task list becomes the blueprint for your Funnel structure and tagging plan. You now know what matters most from a user behavior standpoint, and you've built early alignment with the product team in a way that still serves both their questions and your executive metrics.
Top Task Analysis also helps you avoid over-tagging. You're not tracking every interaction on the screen. You're tagging only what supports meaningful workflows. This is where research operations starts to pay off. You're creating scalable structure that focuses on signal, not noise.
Read more about how I conduct a good top task analysis here.
Now Build Funnels
Once your top tasks are defined, you can start building Funnels. In Pendo, a Funnel is a predefined sequence of steps that represent a task a user is trying to complete. Funnels let you measure things like task completion rate, drop-off points, and time on task. They are structured, repeatable, and easy to compare across products, which makes them perfect for your first wave of rollout.
A strong Funnel has three parts:
A start trigger. This might be something like clicking "Create Report" or loading a setup screen.
One or more meaningful midpoint interactions. These are actions like applying filters, clicking "Next," or entering required inputs.
A completion trigger. This could be clicking "Submit," "Save," or selecting "Done" to finalize the task.
You don't need to over-engineer this. In fact, shorter Funnels are often better. I recommend 3 to 6 steps for most product workflows. If you go too short, like 1 or 2, you don't get enough data to understand behavior. If you go too long, like 7 or more steps, the Funnel can become noisy and hard to interpret. Optional flows and edge cases start to muddy the signal. For the initial rollout, simple Funnels have proven time and time again to be the best thing to set up first. Don’t get me wrong. Once you have all of your products tagged, your best-guess Funnels in place, and executive dashboards up and running, giving product teams the opportunity to dive deeper with Paths and Journeys is extremely powerful. That’s where the real user-centered value starts to emerge.
From a strategic point of view, you need a solid foundation to start from, and I have never gone wrong with a Funnel-first approach.
Here's a quick reference guide I share with teams during onboarding. It helps them understand what kind of Pendo data types belong in a good Funnel.
Guide: How Tagged Elements Relate to Funnels
✅ Features (Best for Funnels)
What they are: Clicks or interactions on UI elements like buttons, links, or toggles
Why they're ideal:
Provide precise timestamps
Reflect clear user intent
Let you mark the beginning and end of tasks
Best used for:
Task completion rates
Time on task
Funnel drop-off tracking
❌ Pages (Not good for Funnels)
What they are: URLs or screen views
Why they fall short:
Triggered passively, not through intent
Overcounted during refreshes or idle time
Hard to interpret meaningfully
Better used for:
Navigation flow
Path analysis
Identifying discrete and individual user entry and exit points
🚨 IMPORTANT: One caveat to this recommendation: The rare case of a Funnel's exit interaction being a static, non-dynamically generated confirmation page.
⚠️ Track Events (Okay, but wayyyy more effort)
What they are: Custom events set up by devs
Why they're mixed:
Flexible and accurate when implemented correctly
Require more time and dev support
Use them when:
Tracking backend or system actions
Custom UI components need additional instrumentation
❌ Guides (Not for Funnels)
What they are: Tooltips, pop-ups, or walkthroughs created in-app
Why they fall short:
Are triggered by the system, not by user behavior
Can mislead Funnel logic since they simulate interaction
Better used for:
Onboarding
Highlighting new features
Measuring guide engagement
Funnels are the one Pendo feature I rely on to build early trust with both executive teams and product stakeholders. They provide the structure executives need to see usage patterns and the clarity product teams need to improve workflows.
Start here, and you'll be in a much better position to layer on more exploratory tools like Paths and Journeys later.
Funnels vs. Paths vs. Journeys
Pendo offers a variety of tools to help teams understand user behavior. The three that come up most often are Funnels, Paths, and Journeys. Each has its purpose. But if you're responsible for setting up Pendo in a complex org, the order in which you introduce these tools matters.
You already know how Funnels work. So here’s how Paths and Journeys are different:
Paths are automatically generated maps that show what users did immediately before or after a specific action. They’re helpful when you want to explore behavior and surface unexpected detours, loops, or alternate routes through the product.
Journeys track behavior over time. They let you segment users by engagement patterns, like frequency, recency, or feature usage, and help uncover trends across different cohorts.
Each of these tools has its place, but they serve different purposes. Funnels are best for measuring known workflows. Paths and Journeys are better for uncovering new questions once you already have a baseline in place.
All three have value. But in the early stages of rollout, Funnels are the most reliable tool for building a usable dataset. You define them in advance. They give you the kind of metrics executives can interpret without a caveat.
That consistency is critical when you need to compare data across multiple products.
Paths and Journeys can support deeper exploration later, but they rely on existing tags and usage history. Funnels let you create structured insight from day one, as long as they're tied to clearly defined tasks.
There's also a sequencing benefit. Funnels produce benchmarks. Those benchmarks give stakeholders a reference point. Once they have that, product teams tend to become more curious. They start asking questions about drop-off, edge cases, and variant behaviors. That's when Paths and Journeys start to shine. They help teams investigate what the Funnels don't explain.
It's not about choosing one and ignoring the others. It's about leading with structure so the exploratory tools have context. Start with what you can trust. Then let curiosity grow from there.
Pull, Not Push
One of the biggest mistakes I see in analytics rollouts is the belief that you have to convince teams to care. Internal champions get stuck hosting training sessions, sharing documentation, or trying to explain the value of data tools in abstract terms. Everyone nods. Few follow through though.
If you are the one responsible for operationalizing Pendo, I recommend skipping the lecture circuit entirely. Instead, build a dashboard that gives teams something meaningful to react to from the start. Make sure every product team has at least one meaningful Funnel aligned to a top task. Feed that into a shared executive view.
When leaders start asking questions about what they see in the dashboard, the product teams pay attention. Now there is a direct line between how well their product is performing and what the C-suite sees. The need for better insight becomes obvious. You are no longer trying to persuade anyone. The system is doing that work for you.
This is where Funnels are especially valuable. They give you clear, consistent metrics that are easy to compare, and you can create them quickly because your first iteration is just an educated best guess. Completion rate, time on task, and drop-off points are numbers that carry weight.
Even teams that were initially skeptical start to engage more once they see how their product stacks up against others.
At this stage, you'll often hear product teams ask about refining their Funnels or start exploring Paths and Journeys on their own. That is the moment you've earned real traction. The tool is no longer something you're pushing. It’s being pulled into their development processes by them because it’s helping the team better understand their users in the real world.
This approach works because it aligns incentives. It is part of my Opt-in Strategy for gaining bottom-up influence. Executives get visibility. Product teams get actionable data. And you, as the research ops pros, are not trying to sell the value of analytics. You're just making it visible.
Executive Dashboards
Once your Funnels are in place and tagged against real top tasks, you can start building the kind of executive dashboard that Pendo is actually good at. This is where your work as a UX research ops pro becomes most visible.
Google Analytics can tell you how many people visited a page. It can show bounce rates and general traffic patterns. But it cannot tell you whether users are completing key workflows or where they fall off in the middle of a task. e.g., things that actually drive revenue and help calculate ROI. That is where Pendo provides a different level of value.
Insights your dashboards can highlight when driven by Funnels:
Task completion rate across different applications and user types
Drop-off points that show exactly where users exit a workflow
Time on task for common activities, helping you spot inefficiencies
Feature adoption trends tied to specific interactions, not just clicks
Funnel comparisons between teams or releases to track improvements
Workflow-level metrics that show friction, not just usage
This is not surface-level analytics. These are signals that help leaders make decisions about where to invest, which experiences are improving, and which products need support.
You can also pair these behavioral metrics with standardized UX surveys. Things like NPS, SUS, or SUPR-Q give you attitudinal data that can be triangulated with what users are doing in the product. When collected consistently across all applications, these surveys let you compare sentiment just like you compare usage.
When your Funnels are based on top tasks and mapped to leadership goals, your dashboard becomes useful on day one.
Keep Guides on a Short Leash
Pendo Guides are often the most exciting part of the platform for product managers. With just a few clicks, they can launch tooltips, walkthroughs, modals, or banners inside the app without writing code. That kind of power can be helpful when used carefully. But it also comes with risk.
In almost every rollout I've supported, Guides have been overused too early. PMs want to fix onboarding, explain new features, or test messaging. But without structure or oversight, these Guides often end up harming basic usability, overlapping with each other, or interrupting workflows in ways that are difficult to track. As a result, they rarely get identified until it’s too late.
From a UX research ops standpoint, this creates two problems. First, the user experience becomes inconsistent. Users might see five different Guides in one session, all triggered independently by different teams. Second, the data becomes unreliable. If a Guide forces a user to click something, that click can show up in your Funnels and distort what looks like intentional behavior.
My advice is not to avoid Guides completely. Just delay their widespread use until you have a stable analytics foundation.
Start by tagging your top tasks, building meaningful Funnels, and creating a shared view of usage. Once that is working, you can introduce Guides slowly, with a plan to monitor impact.
Treat Guides like any other UX project. If they are going to be part of the user experience, they need to be designed, tested, and measured. And just like your tagging plan, their use should support real user goals, not just internal priorities.
You can always give product teams the freedom to use Guides. But if you do, make sure they understand the tradeoffs. Interrupting users should be very very rare. And when the org is still learning how to use Pendo well, a smaller number of well-designed Guides will serve everyone better than a pile of overlapping experiments.
Read my thoughts on how Pendo Guides should be used here.
Operationalize Evaluative Data First
A lot of teams hesitate when asked to define Funnels early. They say they want to observe user behavior first, explore different workflows, or wait until they have more usage data. That impulse makes sense. It comes from a desire to be thoughtful. But when you are rolling out Pendo across a large org, waiting for perfect clarity can stall the entire system.
This is why I always recommend starting with evaluative tools first. Funnels are designed to measure structured tasks. If you build them around top tasks that are already known and widely used, you do not need to wait. You can start collecting meaningful data immediately.
Those other tools are powerful, especially when used to refine or expand your understanding of user behavior. They help product teams identify unexpected friction points or new entry flows. But if you try to start there, you often end up with fragmented exploration that never connects back to real business outcomes.
The best approach is to start with the structure that supports shared insight. Funnels do that.
Once the data is flowing and the foundation is in place, then it makes sense to explore. Discovery becomes more effective when it builds on something solid.
This is what makes a research operations mindset so valuable. You are not just choosing tools. You are sequencing them in a way that makes the whole system more useful.
Make the First Insight Useful
If there is one takeaway from all of this, it is that your first goal when rolling out Pendo should not be feature coverage. It should be alignment. You are not trying to tag everything. You are trying to track what matters most and build a foundation that supports scale.
Start with strategic conversations. Use Top Task Analysis to ground your tagging. Build short, intentional Funnels. Skip auto-tagging and delay Guide usage until your foundation is stable. And most of all, create a dashboard that shows something real from day one.
Once executives see the data, they will ask for more. Once product teams see how their workflows perform in comparison to others, they will become more invested. At that point, the system starts to pull itself forward. You are no longer the one pushing adoption. You are the one enabling smarter decisions.
That is what good research operations does. It builds systems that make it easier for everyone to care about the right things.
Conclusion
Pendo isn't a tool you can just install and hope for the best. It's a fully fleshed-out system that reflects the structure you give it. If that structure is clear, intentional, and aligned with real user tasks, it will give you behavioral insights that actually drive decisions. If that structure is rushed or scattered, you'll spend more time cleaning up tags than learning anything useful.
If you're rolling out Pendo right now or thinking about doing it soon, the most important thing to remember is to focus less on tagging and more on structure. The more exploratory features, including the dreaded Guides, will still be there when you need them. A thoughtful setup upfront will save you tons of confusion and tons of rework later, especially under tight timelines.
How do you onboard Pendo in your org? What strategy do you use to get teams aligned and data flowing? Feel free to share your approach in the comments or send me a message. I’m always up for trading notes.