> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/guides-monitoring/monitor/measure-link-clicks.md).
# Measure link clicks in passes
See which links customers tap inside their wallet pass, and feed those clicks into the marketing stack.
A wallet pass is full of links. The back of a loyalty card points at the online store, the store locator and the terms. An event ticket carries directions, parking and merchandise buttons. A message promotes the current campaign. Every one of those is a touchpoint, and without tracking none of them report anything: the customer leaves for the destination site and the wallet disappears from the attribution chain.
The Wallet Crew tracks those taps automatically. Links in a pass are rewritten so that a tap passes through The Wallet Crew for a fraction of a second, is counted, and then continues to the intended destination. Nothing changes for the customer, who sees the same button and the same label, and the destination page opens as normal.
Link tracking is switched on by default for every pass type.
Real-world examples
* A fashion retailer finds that the "New collection" link on the back of the loyalty card outperforms the same link in email, and moves the campaign budget accordingly.
* A venue sees parking information opened mostly the evening before an event, and schedules the reminder push for that window instead of the morning of.
* A loyalty programme discovers that almost nobody opens the terms and conditions link, and reclaims the space for a benefits summary.
* A brand running a bilingual programme compares click-through on the French and English wording of the same message, and rewrites the weaker one.
* A CRM team triggers a follow-up email when a customer opens the "Book an appointment" link from the pass but does not complete the booking.
## What happens when a customer taps
The redirect is invisible to the customer and produces one click event, which reaches reporting and the marketing stack by the same routes as installs and scans.
```mermaid
flowchart LR
A["Customer taps a link
inside the pass"] --> B["The Wallet Crew
counts the tap"]
B --> C["Destination page opens,
tagged for web analytics"]
B --> D["Click event"]
D --> E["Analytics dashboard"]
D --> F["Marketing platform"]
D --> G["Report and Insights API"]
```
## What gets measured
Each tap is recorded as a single click event describing which pass it came from, which link was tapped and where that link sits in the pass, which wallet the customer uses, the language of the text they read, and the destination they were sent to.
The position of the link is the most useful dimension in practice. A pass can carry a dozen links, and knowing that the store locator outperforms the online store is only possible because each link reports its own position: an action button, the back of the card, a message, and so on.
The language is recorded whenever the link sits in text that has been translated. A pass shown in French and in English stores each version separately, so the same link reports French and English taps as distinct figures rather than a single blended number.
Clicks are counted per tap, not per customer. A customer who opens the same link three times produces three events. Deduplicating into unique openers is a question for the reporting tool.
{% hint style="info" %}
Only web links are tracked. Email and phone links, such as a "Call the store" button, are left exactly as written and report nothing.
{% endhint %}
## Apple and Google do not track the same things
Coverage is not identical across the two wallets, because Apple and Google allow very different things inside a pass. A campaign measured cleanly on Google Wallet can be partly invisible on Apple, and knowing where the gaps are avoids misreading the numbers.
**A link is measured when it is added as a real hyperlink**, a label with a destination behind it, rather than as a web address typed into the text. Both wallets turn typed addresses into tappable links by themselves, and those taps are never counted. Adding links properly in the template is what makes them measurable.
**Google Wallet** measures every link surface: the website and help links, the links section, promotional blocks, and hyperlinks written inside a message.
**Apple Wallet** measures its action buttons and the links on the back of the card. The front of the card renders its text as written, so a link placed there is neither tappable nor measurable, and the back of the card is where a measurable link belongs.
**Apple notifications carry no clickable link.** A pass notification is alert text on the lock screen. When a campaign puts a link in that message, customers reach it by opening the back of the card, and that is where the tap is recorded. Notification reach and link clicks stay two separate figures on Apple.
## What the destination page receives
Forwarding a tap without context would make the wallet invisible in the destination site's own analytics, because the visit would land in direct traffic with no way to attribute it. To prevent that, The Wallet Crew tags the destination URL before redirecting, using standard UTM parameters that any web analytics tool already understands.
The source is reported as `thewalletcrew`, the medium as `apple` or `google`, and the campaign as the position of the link in the pass. Wallet traffic therefore shows up as its own channel, split by wallet, without any work on the destination site.
Campaign URLs that already carry their own tagging are forwarded untouched. If a link in a pass points at a URL that already defines a `utm_source`, The Wallet Crew adds nothing and leaves the existing attribution intact. An existing campaign link can therefore be dropped into a pass without disturbing how it is already being measured.
{% hint style="info" %}
Brands needing something other than UTM tagging, such as a customer identifier for a personalised landing page, a store code or a language parameter, can have the redirect rewritten by a script. This is an integration task; see [Link tracking](https://app.gitbook.com/s/OnaDC4sjKAx53j0QV843/integration-guides/wallet/link-tracking).
{% endhint %}
## Where the clicks appear
**Location:** **Analytics** → **Wallets**
The **Links Opened** tile and the **Evolution of links opened** chart give totals and trends over the selected period, alongside the same figures for installs, uninstalls and updates. In the breakdown table below them, the group-by selector offers a **Link Opened** group that splits clicks by target URL, device, position in the pass, pass type and language, and the view can be exported as CSV.
Positions are shown in plain language rather than internal names, so the breakdown reads directly without a glossary.
Marketing automation connectors also forward each click to the brand's own platform in real time, where it builds segments and triggers scenarios in exactly the same way as any other tracked event. Brands running Bloomreach receive it as `wallet_linkOpened`; see [Events](/connectors/marketing-automation/bloomreach/events.md).
The same events are available for reporting through the pass-level export described in [Report](/guides-monitoring/monitor/report.md), and programmatically through [Query your data — Insights API](/guides-monitoring/monitor/query-your-data-using-insights-api.md) for dashboards and BI workflows.
{% hint style="info" %}
The **Analytics** → **Links** dashboard measures a different thing: distribution links and QR codes used to hand out passes, not links tapped inside a pass. See [Analytics dashboards](/guides-monitoring/monitor/analytics-dashboards.md).
{% endhint %}
## Turn link tracking off
Some programmes cannot use redirects, because of a legal constraint, a destination that rejects extra query parameters, or an external attribution stack that must own the whole chain. Tracking can be disabled for a given pass type.
As a brand manager, open the pass type in **Wallet**, go to **Advanced configuration**, and find the **Link tracking** section. Clear **Enable link tracking** and save. Links in that pass type are then published exactly as written in the template, and produce no click events.
The setting is per pass type, so a brand can track its loyalty card while leaving a co-branded partner pass untouched.
{% hint style="warning" %}
Switching the setting changes the link text stored inside every pass of that type. The change reaches each pass the next time it is regenerated, not immediately, and past clicks are not recalculated. Expect a transition period where the reporting mixes both behaviours.
{% endhint %}
## FAQ
Does the customer see anything different?
No. The pass shows the same label and the same button. The redirect is not visible, and the destination page opens as it would from any other link.
Do tracked links stop working after a while?
No. A tracked link stays valid for as long as the pass exists, so links in a loyalty card issued years ago still work.
Does turning tracking on notify customers?
No. Enabling tracking on a pass that is already installed leaves its text alone until that text changes for a reason of its own, so no alert is raised by the switch itself.
Will this interfere with existing campaign tracking?
No. A destination URL that already carries UTM tagging is forwarded exactly as written. The Wallet Crew only adds its own tagging to links that have none.
What happens if a click cannot be counted?
The customer still reaches the destination. Counting the click and adding the campaign tags are both best-effort and never block the redirect, so a failure there costs a data point rather than a visit.
Can clicks be attributed to a named customer?
Yes, where the pass carries customer identifiers. The click event includes the pass identifiers and metadata, so a connector can attach the click to the matching customer profile in the marketing platform.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.thewalletcrew.io/guides-monitoring/monitor/measure-link-clicks.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.