Coupon extension visibility vs installation: measure both
An installed coupon extension is a possibility; an observed extension session is behaviour. Use both signals to decide what deserves a control.
Jump to a section
In short
If your dashboard says an extension was installed, that tells you a shopper could use it. If it says an extension was detected in a session, that tells you the extension showed up in the journey Benson could observe. Those are different facts, and treating them as one number leads to the wrong control.
What does installation tell you?#
An installation signal is a reach estimate. It answers: which supported coupon or cashback extensions are present in the browser, even before one visibly changes the page? That is useful when an extension is quiet on your store, appears only on certain templates, or waits until a shopper reaches a particular moment.
Benson's installed-extension check is deliberately narrower than a general browser inventory. It looks for a short list of shopping extensions, runs at most once per visit in desktop Chrome and Microsoft Edge, and never runs on checkout pages. The result records matched extension names as part of the visit's events; it does not read the file used to make the check.
The privacy policy explains the check and its consent conditions in full in Installed-extension check. That detail matters when you decide which regions, browsers, and visits can contribute to the comparison.
Installation is therefore a useful denominator only for the traffic that was actually eligible for the check. A percentage of all sessions would imply knowledge Benson does not have. Read the installed share against probed sessions, and keep the raw probe count beside it so a small sample does not look like a precise market estimate.
What does an observed session tell you?#
Session detection is the behaviour signal. It answers: did Benson observe an extension actor in this visit, and what did it do? The dashboard can use that cohort to show extension share, pages visited, pop-ups hidden, codes applied, and order outcomes when the store's order connection is configured.
An observed session can be active without being proof of installation in the separate probe. The extension may have shown a signal on a browser that was not eligible for the probe, the check may not have run, or the extension may have changed its behaviour before the probe completed. Keep the event definitions separate and label the cohort you are using in every decision readout.
The help centre's extension list describes the families Benson currently detects. The extension impact guide shows how to compare the observed extension cohort with human sessions without turning correlation into a causal claim.
Why can an extension be installed but quiet?#
An installed extension can wait for a page or event that is not present in the visit you are looking at. It can also be disabled for a site, blocked by browser settings, or fail to render a surface that Benson can observe. That is not a contradiction; it is the difference between capability and behaviour.
The browser model makes this distinction useful. Chrome content scripts can read and change a page's DOM while running in an isolated world from the page and other scripts. The official Chrome content scripts guide describes both sides of that boundary. A merchant can observe page-level effects without assuming they can inspect an extension's private state.
Use the quiet share as a question, not a verdict. If many eligible visits show installed-but-inactive, ask whether the extension is selective, whether your templates expose the relevant trigger, or whether the installation cohort includes browsers and contexts where the storefront feature cannot run. Do not call those visits “lost” or “protected” until you have an outcome measure.
Which signal should drive a merchant decision?#
Use the signal that matches the decision:
- Should we investigate reach? Start with installed share and probe coverage. It tells you how much eligible traffic may be carrying the extension before it visibly acts.
- Should we hide a surface? Start with observed extension sessions and the pages where the surface appears. A control should target behaviour you can actually change.
- Should we allow or reject a code? Use the tagged extension-session cohort that reaches the code field, then measure accepted codes and order outcomes. Installation alone does not say what code a shopper tried.
- Should we renew a partner? Compare the partner or extension cohort with a fair control. Read how to evaluate an extension partnership before you attach a commission to the installed count.
Keep the report explicit: “checked and installed”, “installed but inactive”, “extension observed”, and “human comparison”. A reader should be able to tell which populations were measured and which were unknowable.
A practical reading order in Benson#
Start in observe mode. Confirm that the install is verified, wait for normal browsing, and read extension sightings by page and source. Then turn on the installed check only where your consent configuration allows it and the browser is eligible. Look at probe coverage before interpreting installed share.
When you are ready to change a rule, put the change behind a holdout. A slice of eligible extension traffic continues without the rule, while the treatment sees it. Read revenue per session, conversion, discount depth, and any code outcome in both arms. The holdout measurement guide covers the setup and the questions to settle before launch.
The useful conclusion is usually narrower than “extensions are everywhere” or “extensions do nothing”. It might be: “This extension is installed in the eligible cohort, appears on cart for a smaller observed cohort, and its pop-up control changes no measured outcome yet.” That is a decision you can revisit with better evidence.
