Measuring integration adoption and engagement

The integration shipped, a few hundred people installed it, and the launch slide said the number was a success. Six months later nobody can say whether the integration is actually doing anything, because the only number anyone ever tracked was installs, and installs are the metric that flatters you the most while telling you the least. An install is a moment of intent. It is someone clicking connect, often to try, sometimes by accident, frequently never to return. Counting installs and calling it adoption is like counting people who walked into a store and calling it revenue. The store needs to know who bought, who came back, and who kept coming. An integration needs the same: not how many connected once, but how many are actively using it and still using it later.

This is an independent guide to measuring integration adoption and engagement, written for a startup that has shipped an integration and now needs to know whether it is working. The right metrics depend on what the integration does, a daily-sync integration and a one-time migration tool are healthy at very different usage rhythms, so treat the specific thresholds here as something to set for your own product rather than universal numbers. What does not change is the structure of honest integration measurement: distinguishing the install from the active connection from the retained user, instrumenting each so you can see them separately, reading them as a funnel rather than a single headline, and using the result to tell a healthy integration from a stalled one. That shape is what this guide covers.

It pairs with our guide to partnership metrics that matter, our influenced vs sourced pipeline guide for connecting usage to revenue, and our partner QBR playbook, where integration adoption is one of the few numbers worth reviewing with the partner every quarter.

The 60-second version

• Installs are a vanity metric on their own. An install is intent, not adoption. Counting installs and stopping there tells you how many people clicked connect, not how many got value.
• Distinguish three things. The install (someone connected once), the active connection (it is actually moving data or doing work), and the retained user (still active weeks later). They are different numbers and they tell different stories.
• Active connection is the real adoption metric. An integration that is installed but idle is not adopted. The number that matters is how many connections are actually doing the job the integration exists to do.
• Retention is the truth serum. Anyone can install. Staying active weeks later is what separates an integration people need from one they tried and abandoned.
• Instrument before you launch, not after. You cannot measure retention you did not start tracking on day one. Decide the events you need and emit them from the start.
• Read it as a funnel. Installed, activated, retained, with the drop-off between each stage visible, so you can see where users fall away and fix the right step.
• Set thresholds for your integration. What counts as active and healthy depends on what the integration does. Define it deliberately rather than borrowing someone else's numbers.

Why installs lie and what to measure instead

The install count is seductive because it goes up and to the right and requires no instrumentation beyond what the marketplace already gives you. It is also the number least connected to whether the integration is working. An install captures a single moment of intent, the click that connects two products, and intent is cheap. People install to evaluate, to satisfy curiosity, to comply with a colleague's suggestion, and a large fraction never do anything with the integration afterward. A headline install number can rise steadily while the integration delivers value to almost no one, and a team that watches only that number will believe the integration is succeeding right up until someone asks how many people actually use it.

What installs hide is the drop-off that happens immediately after the click. Some installed connections never complete setup. Some complete setup and never send a single record through. Some send records for a week and then go quiet. Each of these is a different failure, and the install count blurs them all into one cheerful figure. The job of integration measurement is to pull those stages apart so you can see them, because the difference between an integration that is installed and one that is used is the difference between a number that looks good and a product that works.

The principle that fixes this is the same one that fixes vanity metrics everywhere: measure the behavior that represents value, not the action that represents intent. References on usability and product metrics make the general point that a metric is only useful if it maps to something a user actually accomplished. For an integration, the thing accomplished is not connecting, it is using, and the rest of this guide is about measuring use, in three layers, instrumented deliberately and read as a funnel. We make the broader case for dropping flattering numbers in favor of honest ones in our partnership metrics guide.

Step 1: distinguish install, active connection, and retained usage

The foundation of honest integration measurement is refusing to collapse three different things into one. An install, an active connection, and a retained user are distinct stages, each answering a different question, and the most common mistake is to track only the first and assume it stands for the other two. It does not. Naming the three and measuring them separately is what turns a single misleading headline into a picture you can act on.

The three layers, and what each one actually tells you:

The middle layer, the active connection, is the one most worth your attention, because it is the truest single measure of adoption. An integration that is installed but never moves a record is not adopted in any meaningful sense, no matter how the install count reads. Define "active" concretely for your integration, a connection that has synced data in the last seven days, sent at least one event this week, performed the action it exists to perform within a recent window, and count those. The gap between your install count and your active-connection count is the first and often largest leak, and seeing it is the beginning of fixing it.

The third layer, retention, is what separates a genuinely useful integration from a well-marketed one. Plenty of integrations get installed and even briefly active during an evaluation, then fade as the novelty passes or the use case turns out to be thin. Retained usage, a connection still active a month or a quarter after it went live, is the honest verdict on whether the integration earned a place in the user's workflow. It is harder to game and harder to fake than any install or first-week-active number, which is exactly why it is the metric to trust most.

Step 2: instrument what you want to measure

You cannot measure a behavior you did not instrument, and the painful version of this lesson is discovering after launch that you have no way to know whether last month's installs are still active, because you never emitted the events that would tell you. Instrumentation is a before-launch decision, not an after-the-fact one, and the discipline is to work backwards from the metrics you want to the events you need to emit to compute them.

Start from the three layers and ask what signal each requires:

• Install events. The connection being established, with enough context, which two accounts, when, to tie an install to later activity. The marketplace may give you part of this, but owning your own install event lets you join it to usage.
• Activation events. The first time a connection actually does its job, the first successful sync, the first record sent, the first action completed, so you can measure how many installs ever became active and how long it took.
• Ongoing usage events. A signal each time the integration does meaningful work, emitted continuously, so you can tell which connections are active this week, this month, and which have gone quiet.
• Failure and error events. When a sync fails or a connection breaks, because a connection that silently stops working looks like churn but is actually a fixable problem, and you can only tell the difference if you instrumented the failure.

A few practices keep instrumentation useful rather than a pile of unread events. Emit events that map directly to the metrics you decided to track, rather than logging everything and hoping to make sense of it later, because an analytics stream nobody designed is one nobody can read. Give each event enough identity, which connection, which accounts, to follow a single connection through its whole life from install to active to retained or churned, which is what makes a real funnel possible. And capture failures distinctly from inactivity, since a connection that broke and a connection the user abandoned demand completely different responses, and a metric that lumps them together hides both. General guidance on analytics and measurement makes the same broad point: the value is in deciding what to measure on purpose, not in collecting data indiscriminately.

Step 3: read adoption as a funnel

Once the three layers are instrumented, the way to read them is as a funnel, because the value is not in any single number but in the drop-off between the stages. A funnel makes the leaks visible: how many of the people who installed ever became active, and how many of those who became active were still active a month later. The shape of that funnel tells you not just whether the integration is working but exactly where it is failing, which is what lets you fix the right thing instead of guessing.

A simple integration adoption funnel:

The drop-off between stages is the diagnosis. A big gap between installed and activated means people connect but never get to value, usually a setup, onboarding, or first-run problem: the integration is hard to configure, or the payoff is not obvious enough to push someone through setup. A big gap between activated and retained means people get value once but not durably, a sign the use case is thinner than it looked or the integration solves a one-time need rather than an ongoing one. Each gap points at a different fix, and you cannot see either gap if you only ever counted installs.

This funnel thinking is standard in product analytics, where reading the stages a user passes through, rather than a single top-line count, is how teams find where to improve. The same logic that underlies a conversion funnel applies directly to an integration: each stage is a chance to lose the user, and the stage with the steepest drop is where your next bit of effort returns the most. Reading the funnel over time matters too: a single snapshot tells you the current shape, but the trend across cohorts of installs tells you whether changes you made are actually improving the conversion from install to active to retained.

Step 4: tell a healthy integration from a stalled one

Numbers only help if you know what good looks like, and for an integration that means setting thresholds deliberately rather than borrowing them. What counts as a healthy active rate and a healthy retention curve depends entirely on what the integration does. A daily operational sync should have most active connections used every week and a retention curve that stays high, because if it is valuable people depend on it constantly. A periodic or situational integration is healthy at a much lower frequency, because its job is to be there when needed, not every day. Judging the second by the standard of the first would condemn a perfectly good integration, so the thresholds have to fit the integration's actual purpose.

Signals that an integration is healthy:

• A high install-to-active rate. Most people who connect actually reach value, which says onboarding works and the payoff is clear enough to pull users through setup.
• A retention curve that flattens rather than falling to zero. Some early drop-off is normal, but a curve that levels out means a core of users found durable value and stuck, which is the signal of a real need being met.
• Active connections used at the rhythm the integration intends. A daily-sync integration used daily, a weekly tool used weekly. Usage that matches the integration's purpose is the sign it is doing its job.
• Low silent-failure rates. Connections that keep working rather than quietly breaking, because a high silent-failure rate looks like churn and erodes trust even when the underlying value is real.

Signals that an integration is stalled:

• A wide installed-to-active gap. Lots of installs, few of them ever active, which means the intent is there but the integration is not delivering, usually a setup or first-value problem.
• Retention falling toward zero. Users try it and leave, a sign the use case is thinner than the install count suggested or the value does not recur.
• Active connections used far below the intended rhythm. Connections that are technically active but barely used, which often means the integration is a nice-to-have rather than something woven into the workflow.

This is also the number to bring to a partner conversation. Integration adoption is one of the few metrics worth reviewing in a partner QBR, because a stalled funnel is often something both companies can fix together, a joint onboarding push to close the install-to-active gap, or a campaign to existing shared customers to lift activation. Connecting adoption to revenue, via the influenced vs sourced pipeline lens, also turns a usage chart into a business case: a well-adopted integration that drives or protects revenue justifies the effort to build the next one.

Common mistakes, and the fix

Reporting installs as adoption. The fix: track the active connection, not the install, as your adoption metric. An install is intent and intent is cheap, while an active connection is the integration actually doing its job, which is the only thing that represents value.

Never measuring retention. The fix: instrument ongoing usage from day one and watch the retention curve, not just the first-week active number. Retention is the honest verdict on whether the integration earned a place in the workflow, and it is the metric hardest to fake.

Instrumenting after launch. The fix: decide the events you need before you ship and emit them from the start. You cannot measure retention for a cohort you never started tracking, and adding instrumentation later leaves a permanent blind spot in your earliest, most informative data.

Confusing broken connections with churn. The fix: capture failure and error events distinctly from inactivity. A connection that silently broke is a fixable problem that looks identical to abandonment unless you instrumented the failure, and treating the two the same hides both.

Reading one number instead of a funnel. The fix: read installed, activated, and retained as stages and look at the drop-off between them. The gap between installed and activated and the gap between activated and retained point at different fixes, and a single headline number hides both leaks.

Borrowing someone else's thresholds. The fix: set what counts as active and healthy based on what your integration actually does. A daily sync and a situational tool are healthy at completely different rhythms, and judging one by the other's standard misreads a working integration as a failing one.

FAQ

What is the difference between integration installs and adoption? An install is a single moment of intent, someone clicking to connect two products, while adoption is sustained, valuable use of the integration afterward. The two diverge sharply: a large share of installs never become active, so an install count can rise while almost no one actually uses the integration. The honest adoption metric is the active connection, one that is actually moving data or doing the job the integration exists for, and the truest long-term measure is retained usage, connections still active weeks or months later.

What should I count as an active connection? Define active concretely for what your integration does, then count connections that meet it. For a daily-sync integration, active might mean a connection that has synced in the last seven days. For a situational tool, it might mean one that performed its action within a longer recent window. The point is to pick a definition that maps to the integration actually delivering value, document it, and apply it consistently, so the active number means the same thing every time you report it.

How do I measure retention for an integration? Track whether a connection is still active a set time after it went live, a month and a quarter are common windows, and watch the curve across cohorts of installs rather than a single average. A retention curve that falls toward zero means users try the integration and leave, while one that flattens means a core of users found durable value. Measuring this requires emitting ongoing usage events from launch, because you cannot reconstruct retention for connections you never instrumented.

What instrumentation do I need to measure integration adoption? At minimum, install events, activation events for the first time a connection does its job, ongoing usage events emitted whenever it does meaningful work, and failure events distinct from inactivity. Each event needs enough identity, which connection and which accounts, to follow a single connection from install through active to retained or churned. Decide these before you launch and work backwards from the metrics you want, because instrumentation added after the fact leaves a permanent gap in your earliest data.

How do I know if my integration's adoption is healthy? Set thresholds that fit what the integration does rather than borrowing them. Broadly, a healthy integration shows a high install-to-active rate, a retention curve that flattens instead of falling to zero, active connections used at the rhythm the integration intends, and low rates of silent failure. A stalled one shows a wide installed-to-active gap, retention trending toward zero, or active connections used far below the intended frequency. The diagnosis is in which stage of the funnel leaks, because each leak points at a different fix.

How does integration adoption connect to revenue? A well-adopted integration tends to protect and grow revenue, because customers who weave an integration into their workflow are stickier and harder to displace, and a high active and retained rate among shared customers is a sign the partnership is delivering. You can connect adoption to revenue through the sourced and influenced lens, treating a strong integration as something that influences retention and expansion. That link is what turns an adoption funnel from an engineering chart into a business case for building the next integration, and it is why adoption belongs in a partner QBR.

Further reading

• Partnership metrics that matter for the broader case for tracking honest numbers over flattering ones.
• Influenced vs sourced pipeline for connecting integration adoption to revenue.
• How to run a partner QBR for reviewing adoption with the partner and fixing a stalled funnel together.
• Conversion funnel for the funnel thinking that underlies reading adoption as stages with drop-off.
• Cohort analysis for measuring retention across groups of installs over time.
• Customer retention for why durable usage, not first-touch, is the honest measure of value.
• Nielsen Norman Group on usability metrics for why a metric is only useful if it maps to something a user actually accomplished.
• Harvard Business Review's collection on analytics and data science for the discipline of measuring what matters on purpose rather than collecting data indiscriminately.

The short version

Measuring integration adoption starts with refusing to treat installs as success. An install is a moment of intent and intent is cheap, so a rising install count can mask an integration almost no one uses. Distinguish three layers: the install, the active connection that is actually doing the integration's job, and the retained user still active weeks later. The active connection is the real adoption metric and retention is the honest verdict on whether the integration earned a place in the workflow. Instrument all three before you launch, because you cannot measure retention for a cohort you never tracked, and capture failures distinctly from inactivity so a broken connection does not look like churn. Read the three layers as a funnel and study the drop-off, because the gap between installed and activated is a first-value problem and the gap between activated and retained is a durability problem, and each points at a different fix. Set thresholds that fit what your integration actually does, then bring the funnel to your partner reviews, where a stalled stage is often something both companies can fix together.

If you want help instrumenting and reading your integration's adoption, a Partner Audit looks at how your integrations are measured, where the funnel leaks, and how adoption ties to revenue, then hands you a concrete plan for what to track and what to fix first.