Analytics and Attribution
Every time a user clicks an OpenLynk deep link, the system captures a set of data points for analytics and attribution. This page explains what data is collected, how UTM parameters work, and how attribution flows through the system.
Click Data
Each click on an OpenLynk link generates a record with the following data:
| Field | Description |
|---|---|
| Timestamp | When the click occurred (UTC) |
| Device type | Mobile, tablet, or desktop |
| Operating system | iOS, Android, Windows, macOS, Linux, etc. |
| Country | Derived from IP geolocation |
| User agent | Full browser/app user-agent string |
| Referrer | The page or app that referred the click |
| UTM parameters | utm_source, utm_medium, utm_campaign, utm_term, utm_content |
| IP hash | SHA-256 hash of the user's IP address |
:::note Privacy IP addresses are never stored in plaintext. OpenLynk hashes all IP addresses using SHA-256 before storage. The hash is used only for deferred deep link matching and is not reversible. :::
UTM Parameters
UTM (Urchin Tracking Module) parameters are standardized query parameters used to track the effectiveness of marketing campaigns. OpenLynk supports all five standard UTM parameters:
| Parameter | Purpose | Example |
|---|---|---|
utm_source | Identifies the traffic source | instagram, newsletter, google |
utm_medium | Identifies the marketing medium | social, email, cpc |
utm_campaign | Identifies the specific campaign | summer-sale, launch-week |
utm_term | Identifies paid search keywords | running-shoes, deep-linking |
utm_content | Differentiates ad variations | hero-banner, sidebar-cta |
How UTM Parameters Flow
- Link creation — UTM parameters are stored in the link's metadata when the link is created (via dashboard or SDK)
- Click recording — when the link is clicked, UTM parameters from metadata are included in the click record
- Redirect — UTM parameters are appended to the redirect URL as query parameters
- SDK access — when the deep link opens the app, UTM parameters are available in the
metadatamap. The Flutter SDK also provides convenience getters (utmSource,utmCampaign, etc.) onRestoredLink
Best Practices for UTM Naming
- Use lowercase consistently (
instagramnotInstagram) - Use hyphens instead of spaces or underscores (
summer-salenotsummer saleorsummer_sale) - Establish a naming convention across your team and document it
- Keep
utm_sourcevalues consistent across links (alwaysinstagram, never mixingigandinstagram) - Use
utm_campaignto group links that belong to the same initiative
Click Attribution
Click attribution connects a link click to the campaign and channel that generated it. Because OpenLynk stores UTM parameters with each click record, you can analyze:
- Which sources drive the most clicks
- Which campaigns have the highest click-through rates
- How click volume varies by device type and geography
- Which UTM combinations lead to app installs (via deferred deep linking)
Deferred Deep Linking Analytics
OpenLynk tracks additional metrics specific to deferred deep linking:
| Metric | Description |
|---|---|
| Pending links created | Number of pending link records stored (user clicked but did not have the app) |
| Pending links restored | Number of pending links successfully matched after app install |
| Restore rate | Percentage of pending links that were restored (restored / created) |
These metrics help you understand the effectiveness of your deferred deep linking setup and identify drop-off points in the install funnel.
SDK Install Tracking
The OpenLynk SDK sends periodic heartbeats to track installations:
| Data Point | Description |
|---|---|
| First seen | Timestamp of the first heartbeat from a device (approximates install time) |
| Last seen | Timestamp of the most recent heartbeat |
| Device fingerprint | Anonymized device identifier used for matching |
Heartbeats are throttled to once per 24 hours per device to minimize network overhead.
Install tracking is automatic. The SDK sends a heartbeat during init() with no additional configuration required.
Cohort Retention Analysis
Cohort analysis uses SDK heartbeat data to measure user retention over time. Users are grouped into cohorts based on when they first installed your app (their first heartbeat), and retention is calculated by checking whether each user's most recent heartbeat (last_seen_at) exceeds specific time thresholds after their install date (first_seen_at).
| Retention Window | Time Since Install | What It Measures |
|---|---|---|
| Week 1 | 7 days | Early engagement — did users return after the first session? |
| Week 2 | 14 days | Habit formation — are users integrating the app into their routine? |
| Week 4 | 28 days | Medium-term retention — is the app providing ongoing value? |
| Week 8 | 56 days | Long-term retention — are users becoming committed? |
Cohorts can be grouped by week or by month. Weekly grouping provides more granular visibility into how recent changes affect retention. Monthly grouping smooths out noise and is better for reporting.
Cohort analysis requires the Starter plan or above. The legacy Free plan includes basic analytics only. See Pricing for details.
For a walkthrough of how to read the cohort grid in the dashboard, see View Analytics — Cohorts View.
What's Next?
- View analytics in the OpenLynk dashboard
- Learn about deferred deep linking to understand the full attribution flow
- Review the Data Types Reference for UTM parameter access in the SDK