Last 30 days selects the period being reported. The selected dates and daily buckets use the organization timezone. The trend badges compare the selected period with the immediately preceding period of the same length.
Revenue adds the provider totals recorded for your Zellify funnels in the selected period. A transaction is included once it has been completed, using its recorded completion date. Refunds are not subtracted, and a recorded total can differ from the cash collected from the buyer.
These payments can be:
Currency: payment amounts are stored in the currency the customer paid, in that currency’s smallest units. They are converted to USD when the report is queried, using the daily exchange rate for the recorded UTC completion date. The rate-refresh job runs every six hours; the rates themselves are daily.
Conversions count completed, funnel-originated payments, deduplicated by session_id within each day. Two payments from the same session on the same day count as one conversion. Automatic subscription renewals do not add conversions.
The Conversions headline is the sum of the daily conversion counts. A session can count again if it completes another funnel-originated payment on a different day.
Each point on the chart shows that day’s conversion rate. The headline shows total conversions divided by total visits across the selected period. This gives days with more visits more weight.
Example: a two-day reporting period.
| Day | Conversions | Visits | Daily rate |
|---|---|---|---|
| Day 1 | 1 | 10 | 10% |
| Day 2 | 9 | 30 | 30% |
The period’s conversion rate is (1 + 9) ÷ (10 + 30) × 100 = 25%. Giving both days equal weight would produce 20%.
One session can visit on Monday, then convert on Tuesday and Wednesday. Across those three days, the period has two conversions and one visit, so the rate is 200%. If a selected period has zero visits, the UI shows 0% even when it has conversions.
MRR (monthly recurring revenue) is what all active subscriptions would bring in per month if nothing changed. Each subscription is priced from its product record in Tinybird, which stores the recurring price already converted to a monthly amount, times the subscription's quantity.
Each date on the chart has its own MRR value. The headline shows the value for the last day of the selected period.
| Recurring price | Calculation | Monthly amount |
|---|---|---|
| $12 every month | $12 ÷ 1 | $12 |
| $120 every year | $120 ÷ 12 | $10 |
| $30 every 3 months | $30 ÷ 3 | $10 |
| $12 every week | $12 × 52 ÷ 12 | $52 |
One-time products do not contribute to MRR.
Payment and subscription events supply product details. Zellify saves the price, currency, and billing period in Tinybird, the analytics database. Successful-payment, failed-payment, and subscription events can update this data; refunds and voids do not update it.
Within an organization, the payment provider, product ID, and price ID identify the shared product-price record. Subscriptions referring to that record use the same saved price. There is not a separate product-price record for each customer.
The latest record written by the worker is used. An older event processed later can therefore replace a price saved earlier. For Solidgate, the mapping uses the product ID in place of a distinct price ID. A $15 monthly product can therefore be replaced by a $6 partial-capture or failed-order write using that identity. Stripe and Paddle can likewise save a catalog price instead of the localized price charged, so MRR can be wrong even when the transaction total is right.
The solid line shows MRR for each day in the selected period. The dashed line overlays the same day position from the immediately preceding equal-length period.
Product revenue is Revenue split by product and price. Each row adds the payment lines for one product at one price in the selected period, converted to USD.
One-time payments, upsells, subscription starts, and renewals can all contribute. Refunded sales remain included, and test payments are included too.
The Visitors column counts recorded sessions in each funnel that started during the selected period. Reopening the funnel in the same browser does not add a visitor. Opening a different funnel does, because each funnel keeps its own session.
A session is a cookie. When someone opens a funnel, the server issues a session ID and the page stores it in a cookie named _umc_<funnel id> on the address the funnel was opened from. Nothing else remembers the person: no localStorage, no account, no fingerprint. On the next visit the server reads that cookie and hands the same session back.
So "one visitor" means one browser on one device at one address. The same person on their phone and their laptop is two visitors. A different browser, a private window, or cleared cookies is a new visitor. The cookie lasts 400 days, so someone who comes back months later is still the same visitor, and because a visit is dated to the day the session started, that return does not add a visit to the current period at all.
The cookie name carries the funnel ID, so the same browser gets a separate session for every funnel it opens.
% Conversion is the number of sessions with included payments divided by that row's visitors.
A payment counts here under the same rules as the Conversions headline: completed (a refund does not undo it), a web purchase rather than an automatic renewal, dated inside the selected period, attributed to this funnel, and carrying a session ID. It is read from provider notifications; no browser event is needed.
The provider quirks from the Conversions section apply here too: a Paddle card update or a recovered Solidgate renewal can count, and a free trial counts on Stripe and Paddle but not on Inflow or Solidgate.
These three cards can show numbers up to five minutes old. The server reuses its last result for that long, and reloading the page does not bypass it.
The Visitors column counts sessions that started in the selected period, whose attributed link is this one, and whose funnel is one the link currently points to. A session gets its link from the link it arrived through, and normally keeps it. Every session is counted under exactly one link, or under none.
How a session gets a link. Clicking a link goes through /zc/<link id>, which picks the destination funnel and sends the browser there. Along the way it sets a 30-day cookie on that address saying "this funnel was reached through link N". When the funnel page loads, the server reads that cookie, writes the link into the session (the _umc_ cookie from the Funnel card), and every event the session sends from then on carries it. The click itself records nothing; the session and its link exist only once the page has loaded and sent an event.
Once set, the link sticks. A later visit to the same funnel through a different link does not change it: the browser already has a session for that funnel, and the server keeps its link. The link changes only when the new URL carries zl_network= with one of google, meta, snapchat, or tiktok, which is what a real ad click carries. A click ID or UTM parameter alone is not enough. A direct visit without any link keeps the earlier link too.
Nothing stored is ever rewritten. A change means the server issues a new signed session cookie carrying the new link; events sent from then on carry it while the earlier events keep the old one. The report picks the link on the session's most recent event, over the session's whole life, and dates the session to its first event. So a session that started in March through Link A and sent events under Link B after an ad click in June counts as a March visitor for Link B, and a March report opened today shows it under B.
A session that never came through a link counts in the Funnel card and in Total Funnel Visits, but under no link here.
% Conversion is the number of sessions with included payments credited to this link divided by that row's visitors.
A payment is included under the same rules as the Conversions headline: completed (a refund does not undo it), a web purchase rather than an automatic renewal, dated inside the period, and carrying a session ID. A converting session counts once for the whole period, as in the Funnel card.
Where the payment's link comes from. At checkout the page copies the session's link, experiment, funnel and session ID into the payment provider's metadata. The provider echoes that metadata back in its webhook, and that is what the payment is credited to. Nothing else can attribute a payment: if the metadata is missing, the payment has no link, no session, and counts nowhere on this card.
The payment's link is frozen at checkout. If the session later sends events under another link after an ad click, the visit follows the newer link but the payment stays with the one it was made under. Link A can then show a conversion with no visitor, and its rate can pass 100%.
Total Active Subscribers is how many subscriptions were live on each day. A subscription is live from its start through the day it was cancelled, that day included. The number above the chart is the count on the last day of the period.
A subscription is identified by its provider and subscription ID. One customer with two subscriptions counts as two; one subscription with a quantity of five counts as one.
It uses the same subscriptions as MRR, under the same rules, including that a subscription cancelled and later reactivated counts for the gap. Unlike MRR it needs no saved price, so a subscription can be counted here and still be missing from MRR.
Total Funnel Visits is how many sessions started on each day across the selected funnels, added up. A session starts with its first recorded event in a funnel. It is the same session described in the Funnel card, and the same count the Conversion Rate above divides by.
Any event the page sends counts: a page view, a page completion, an email capture. Opening a link or loading a page that never sends an event records nothing. Events are timestamped in the browser, so an older event arriving late can move a session's start to an earlier day.
Counts appear once a background job has stored the events, usually within seconds. Requests recognised as bots are skipped.
This page and the next assume the Home chapters: what a session is (Funnel breakdown), how a session gets its link (Link breakdown), and what counts as a conversion. The captures show organization BDCD and link 55, "Meta | USD_EN", over a year.
The Visitors and Revenue columns are not calculated when you open the page. A background job computes them every 15 minutes for four fixed windows and stores the result; Metrics period picks which stored window you see. The windows are the last 1, 7, 30 or 365 days in UTC, today included.
Every 15 minutes a job asks the analytics database for each link's visitors and revenue over each of the four windows and replaces the stored rows. The page reads the rows. There is no "as of" time on the page and no check of how old a row is: if the job stops, the numbers freeze and nothing says so. A link with no stored row shows 0 visitors and $0.
"Last year" is those 365 UTC days. The link page's "Last 12 months" is the same calendar date a year ago through today, in the organization's timezone. The labels differ because the windows are built differently; the difference is a day or two at the edges.
Visitors is the number of sessions that viewed a page through this link at any point in the window. Revenue is the total of web purchases credited to the link in the window, in USD.
The fact is a page view event that carries this link's ID. A session counts once per link for the whole window, whichever day it happened, including a session that started before the window and came back during it. A session that came through two links counts under both. Unlike Home and the link page, the list does not care which funnel the link points to today: traffic to a funnel the link no longer targets still counts.
A completed payment whose recorded link is this one and whose completion date falls in the UTC window. Refunded sales stay in. Test-mode payments count. Automatic renewals do not: the list keeps web purchases only. If any included payment has no exchange rate, the whole cell shows a dash rather than a partial total.
The same link over the same nominal year: 119,759 visitors and $144,578 here, 98.1K visitors and $146.7K on the link's own page. Neither number is wrong by its own definition. They define visitor, day and scope differently, on every axis at once.
| Links list | Link page | |
|---|---|---|
| Visitor | a session that viewed a page through the link | a session that started in the period and whose latest link is this one |
| Counted | once per link for the whole window | once on the day the session started |
| Funnel scope | none | only funnels the link points to today |
| Days | UTC, exactly 365 | organization timezone, calendar year |
| Revenue | web purchases only | all payments, renewals included |
| Freshness | 15-minute snapshot, age not shown | computed when the page loads |
The link page has one date range for everything below it. The Audience Analysis tab and the Link Configuration card are not covered here.
Last 12 months selects the period, and every badge compares it with the 12 months before. Days are calendar days in the organization's timezone, the same rule as Home. If the funnel is younger than the period, the query starts at the funnel's creation date.
Revenue, Conversions and Total Visitors are the Home numbers restricted to this link. Conversion Rate is conversions divided by visitors, and ARPU is revenue divided by visitors.
Total Visitors: sessions that started in the period, in one of the funnels the link points to today, whose latest link is this one. The same rule as the Home Link card.
Conversions: sessions with a completed web purchase carrying this link, counted once per day, days added up. Renewals are not conversions.
Revenue: every completed payment carrying this link on one of those funnels, purchases and renewals alike, refunds not subtracted, test mode included.
A link that points straight at an experiment also requires the payment to carry that experiment. A link with country rules does not.
The line is the selected card's value for each day, Revenue by default; click another card to switch. The solid line is the selected period and the dashed line the period before it. Over 12 months the chart still holds one point per day; only the axis labels are thinned.
Each bar is one page of the funnel, in the order the funnel is built today. Its height is the share of sessions that reached the page and then completed it. Under each bar: that share, and the number of sessions that reached the page.
Reached is a page view event from a session, counted once per session. Completed is a page completed event, sent when the visitor moves forward to the next page through the funnel's own button or answer. Pressing back, reloading, closing the tab, or leaving to another site does not complete a page.
If more sessions completed a page than viewed it, which happens when a view was lost in transit, the visitor count is raised to the completion count so the bar never exceeds 100%.
Hovering a bar shows Retained, the completions, and Churned, the sessions that reached the page and never completed it. Churned here is page drop-off; it has nothing to do with subscription churn.
The flow is the funnel's routing as it is built today, with each page's numbers from the bars and, on each arrow, the share of sessions that moved along it.
Every completion event records where the visitor went next. An arrow's percentage is the sessions that completed the source page towards that destination, divided by the sessions that reached the source page. Where a page splits traffic between variants, the arrows show the configured split, not a measurement.
Avg. Time is the average of the recorded time on the page across completions, keeping only durations between one second and one hour, rounded to whole seconds. Sessions that never completed the page contribute no time.
User Retention claims to show, for the customers who started the selected product through this link in the period, the share still subscribed N days later. The number above the chart is the share with no recorded cancellation.
The chart does not compute that. It takes every payment in the period, groups the payers by customer, and for each day on the axis counts who has no cancellation dated before that day. Six things go wrong on the way.
| Today | Should be |
|---|---|
| One-time products are offered, and the first product is selected by default. A one-time purchase cannot be cancelled, so the line is 100% forever; that is the captured chart. | Recurring products only. |
| The date range picks payments in the period, so a renewal in March pulls in a customer who started last year. | The date range picks customers by the day they started. Nothing else. |
| The axis is as long as the date range, and a customer who started yesterday counts as retained at day 365. | Day N counts only customers who are at least N days old. |
| A cancel-at-period-end counts from the day it was requested. | From the end of the paid period. |
| One cancelled subscription marks the customer churned, even on the curve of a different product they still pay for. | Retention per subscription of the selected product. |
| Trials are subscriptions from the trial start, so a free trial that never paid counts as retained until the provider reports a cancellation. | Decide whether the cohort starts at trial start or first payment, and say which. |
Rows are when customers started, columns are how old they are, and a cell is blank until that cohort has reached that age. The date range chooses the rows.
One line per row gives the curve version; the current widget is that line with every row counted at every age, whether reached or not.
Purchased Products splits the link's purchases by product and price, by number of purchases, not by revenue. A $99 yearly plan bought once and a $15 upsell bought once are the same size. Revenue appears only when you hover.
A purchase is one product line on a completed or refunded payment carrying this link on one of the link's current funnels, dated in the period. A payment with two products counts twice. Renewals count as purchases here, and test-mode payments are included. Clicking the legend hides slices but does not recompute the percentages.
Question Answers shows, for one question at a time, how the answers split among sessions that came through this link in the period. The percentages are shares of answers given, not of people.
For a question where a session can tick several options, each ticked option counts once, so the percentages are shares of all ticks. A session that answered in two of the link's funnels counts twice. Only each session's latest answer counts, and it counts in the period when it was last changed: a session that answered in March and changed its answer in April shows the April answer only, under April.
A refunded payment is still a completed one. Refunding does not remove the conversion, the same way it does not subtract from Revenue.