Skip to main content

Web Analytics

Understand the web side of your link journeys — sessions, engagement, and conversions captured by the web pixel and attributed back to the links that drove them.

Overview​

The Web tab in Analytics turns raw pixel events into a full picture of on-site behavior:

  • Sessions & visitors — total sessions, unique visitors (new vs returning), page views
  • Engagement — bounce rate, pages per session, average time on page
  • Conversions & revenue — conversion counts, total revenue, average order value
  • Breakdowns — slice every metric by source, device, country, browser, referrer, and more
  • Per-link drill-in — the web performance of a single link
  • Journeys — top entry and exit pages
  • Period comparison — every headline metric shows the change versus the previous equal-length period
Requires the web pixel

Web Analytics is populated by the web pixel. Install the snippet on your site first; data appears within a minute or two of the first page load.

Getting there​

Open Analytics and select the Web tab. Use the time-range selector (7 / 30 / 90 / 365 days) to scope every card on the page. To see a single link's web data, select the link — the view filters to that link and a cross-surface summary appears (see App Analytics → Cross-surface).

Headline metrics​

MetricMeaning
SessionsDistinct visits. A session belongs to one browser tab and ends when the tab closes.
Unique visitorsDistinct visitor IDs — only populated when the pixel runs with data-visitors="true".
Page viewsTotal page_view events, including SPA route changes.
Bounce rateShare of sessions with exactly one page view.
Pages / sessionPage views divided by sessions.
Avg time on pageMean engaged time, derived from engagement events.
Conversionsconversion events (declarative, programmatic, and autocapture). Once you set goals, only goal events count.
RevenueSum of the value of conversions. On this tab amounts in different currencies are added together; the Events page lists web revenue per currency.
Avg order valueRevenue divided by revenue-bearing conversions.

Page views, sessions, conversions, revenue and conversion rate are shown alongside their change versus the previous period of the same length (e.g. the last 30 days versus the 30 days before that).

Breakdowns​

The breakdown card lets you slice any metric by a dimension. Switch the dimension to see where sessions, conversions, and revenue come from:

DimensionExamples
Source / Medium / CampaignUTM values from the landing URL
ContentThe utm_content value — slice by which on-page placement or CTA drove the visit
ReferrerThe referring domain
Referrer categorySearch, social, referral, or direct
PageThe page the event happened on
DeviceDesktop, mobile, tablet
BrowserBrowser family
CountryDerived from the request IP at ingestion

Geolocation is derived from the request IP and the raw IP is then discarded — see the pixel's privacy behavior.

Select a link to scope the entire Web tab to that link's traffic. This answers "how does this campaign perform on the web?" — its sessions, engagement, conversions, and revenue, with the same period-over-period deltas. It's the web counterpart to the link's app analytics.

Journeys​

The journeys card surfaces the top entry pages (where sessions begin) and top exit pages (where they end). Use it to find the pages that pull visitors in and the pages where they drop off.

Goals & revenue​

Send conversion events from the website
Fire signup, purchase and lead conversions from the site that already has the pixel, with revenue where money changes hands, named to match the workspace's goals.
Show the prompt
I use LinkForty (https://linkforty.com), a deep-linking and mobile attribution platform: short links that route each click to the app, the app store or the web, and record clicks, installs and in-app events per link.

Before writing any code, read the LinkForty documentation index at https://docs.linkforty.com/llms-full.txt and the pages listed under "Docs" below. Work from what the docs say, not from assumptions about how similar products work. If something you need is not in the docs or in this prompt — an ID, a token, a URL — stop and ask me for it rather than inventing a placeholder that looks real.

## Task: send conversion events from this site to LinkForty

The LinkForty pixel is already installed on this site (if it is not, stop and tell me — that is a separate task). Page views are flowing; what is missing is the conversions: the sign-ups, purchases and leads that make a visit worth something. Add them so each one is recorded against the link that brought the visitor.

## Values

- **Site key**: shown in the LinkForty dashboard under Workspace Settings → Web Pixel (it starts with `ws_`). Ask me for it. It is public and belongs in the page HTML; it only lets a page *send* events to my workspace.
- **Not the app token.** The mobile SDK's app token (`at_…`) is a different credential for a different surface; the pixel does not use it. If you find one in this codebase, leave it alone.
- **Allowed domains**: the workspace can restrict which sites may send events (Workspace Settings → Web Pixel → Allowed domains). Events from any other host are dropped silently, so list every hostname this site is served from — production, www and non-www, staging if it should count — and tell me to add any that are missing.
- **Ingestion endpoint**: the default (`https://api.linkforty.com/api/pixel/v1/event`) is right for LinkForty Cloud; leave `data-endpoint` unset.

## How to work

1. **Look before you change anything.** Identify the framework, its version, the navigation/router library and where the app initializes at launch. List the screens (routes) you found, and **ask me which screen each incoming link should open and what parameter it needs** — for example "a link with `productId` opens the product screen". Wait for my answer before editing; do not guess routes.
2. **Work on a new git branch.** If the working tree has uncommitted changes, stop and tell me instead of building on top of them.
3. **Follow the docs pages named below, not memory.** Package names, method names and config keys come from those pages; LinkForty's SDKs are not the same as other attribution SDKs you may know.
4. **Do not invent values.** Anything in "Values" that says "ask me" is something you ask for. Never commit a token to source.
5. **Keep the app working without a link.** A launch with no matching click must behave exactly as before: no crash, no error surfaced to the user, no blocked start-up.
6. **Finish with a summary**: every file you changed and why; the manual steps that remain for me (Apple Team ID and bundle ID, Play signing SHA-256 fingerprint, store listing, a rebuild and reinstall) and where in the LinkForty dashboard each one goes (Workspace Settings → App Configuration); and anything you were unsure about.
7. **Verify.** Run the app once, then check the LinkForty dashboard: the SDK Doctor badge in the sidebar (https://docs.linkforty.com/guides/attribution/sdk-health) should report the SDK as installed. If the MCP server is available, create a test link with `create_link` and open it on a device or simulator; the click and the deep link should reach the screen we agreed on.

## Steps

1. **Confirm the pixel is present** — find the `cdn.linkforty.com/pixel.js` tag and note where it loads. If the site has no pixel, stop here and tell me.
2. **Find the completion points.** Look for the moments a visitor has *finished* something valuable: account created, order confirmed, payment succeeded, demo or contact form submitted, trial started. List them with the file and the exact point in the flow, and **ask me which ones to track and what to call each** before writing anything. Good names are short, stable, lower_snake_case: `signup_completed`, `checkout_completed`, `demo_requested` (https://docs.linkforty.com/guides/analytics/events#event-naming-conventions).
3. **Fire each one at completion, never at render.** A conversion must fire once, when the thing has actually happened — on the success callback, the confirmation page, the server's OK — not when a page loads, a form mounts, or a button becomes visible. A conversion that fires on render inflates the numbers permanently and cannot be undone. If the success moment is only known server-side (payment webhooks), fire it on the confirmation page the user lands on afterwards, guarded so a reload does not fire it twice.
4. **Use the right mechanism** (https://docs.linkforty.com/sdks/web-pixel#tracking-conversions): a plain click that *is* the conversion can use the declarative attribute `data-lf-event="…"`; anything after an async step uses `window.LinkForty.track('event_name', { … })` (https://docs.linkforty.com/sdks/web-pixel#programmatic). Where the code may run before the pixel has loaded, push onto the pre-load queue instead (https://docs.linkforty.com/sdks/web-pixel#tracking-before-the-pixel-loads).
5. **Put money in `value`.** `value` is the amount LinkForty counts as revenue: for a purchase, pass `{ value: <number>, currency: '<ISO 4217 code>' }` (`data-lf-value` in the declarative form) so it rolls up under Goals & revenue (https://docs.linkforty.com/guides/analytics/web-analytics#goals--revenue). A property named `revenue` is not counted. Numbers only — no currency symbols, no strings. Only money actually received goes in `value`: a cart total when checkout starts goes under another name such as `cart_total`, or it is counted as revenue. Add a couple of useful flat properties (plan, product id); no names, emails or other personal data.
6. **Tell me the goal names.** Conversion goals are chosen in the dashboard under Analytics → Web → Conversion goals; only names in that list count as conversions once any are configured. List the event names you added so I can enter them.
7. **Verify** by completing one conversion on the running site and watching the network tab for the `conversion` event with the right name and value, then confirming it under Analytics → Web in the LinkForty dashboard.

## Docs

- Tracking conversions (declarative, programmatic, pre-load queue): https://docs.linkforty.com/sdks/web-pixel#tracking-conversions
- Goals & revenue: https://docs.linkforty.com/guides/analytics/web-analytics#goals--revenue
- Event naming: https://docs.linkforty.com/guides/analytics/events#event-naming-conventions
- How a conversion is attributed to a link: https://docs.linkforty.com/guides/analytics/web-analytics#how-web-attribution-works

## Done when

- Each agreed conversion fires exactly once, at completion, with revenue where money changed hands.
- Nothing fires on page load or on form render.
- The conversions appear under Analytics → Web, and I have the list of names to enter under Conversion goals.

When you are done, tell me: exactly which files changed and why, how I can verify it worked end to end (what to tap or run, and what I should see in the LinkForty dashboard), and anything you were unsure about.

A conversion's value is its revenue: it feeds the revenue and average-order-value metrics. Send the amount as data-lf-value, or as the value property of track(), with a currency code if you sell in more than one:

<button data-lf-event="checkout_completed" data-lf-value="49.00">Buy</button>
window.LinkForty.track('checkout_completed', { value: 49.0, currency: 'USD', plan: 'pro' });

Only put money you received in value. An amount that isn't revenue, such as a cart total when checkout starts, goes under another property name (cart_total), or it is counted as revenue.

Goals. With no goals set, every conversion event counts toward conversions and revenue. Choose goals on the Web tab to count only the events that matter (for example purchase and signup_completed); other conversion events are still recorded and listed, but they stop counting.

The dashboard ranks conversion events by volume and revenue so you can see which on-site actions actually drive value. See Tracking conversions for the full pixel API.

How web attribution works​

  1. A visitor clicks a LinkForty link. The redirect appends the click's id to the destination URL as lf_click (on by default; see Click-ID passthrough) along with any UTM parameters the link carries.
  2. The pixel reads the click id and the UTM parameters from the landing URL, remembers them for the session, and attaches them to every event in that session, including on later pages whose URLs carry neither.
  3. At ingestion, LinkForty resolves the click id to the exact originating click and its link, and stamps the event with attributed_link_id. The click id is valid for 7 days after the click. Whenever it can't be resolved — absent, malformed, unknown, belonging to another workspace, or older than 7 days — LinkForty falls back to matching the UTM parameters to the most recent link that carries them.
  4. Attribution is last-click, with the click id as the stronger signal. A later arrival carrying a new click id supersedes the session origin. New UTM parameters replace the session's stored UTM, but they do not displace a stored click id — while a valid lf_click is in the session, that click decides attribution even if the visitor later arrives on a UTM-tagged URL.

The session is stored per origin, so it does not follow a visitor to a second domain on its own. To attribute a conversion on a different site you send visitors to, see Cross-domain tracking.

Events that can't be matched to a link still appear in aggregate web metrics — they just aren't attributed to a specific link.

Best practices​

  1. Tag your links with UTM parameters — the click id attributes untagged link traffic on its own, but UTM parameters are the fallback when it's missing or expired, and they group traffic by campaign in reports. See UTM Parameters.
  2. Track conversions that represent value — signups, purchases, demo requests — and put money in value so it rolls up.
  3. Enable visitor IDs only with consent — unique-visitor counts need data-visitors="true", which is consent-sensitive.
  4. Compare periods — use the built-in deltas rather than eyeballing raw totals.