Quick answer: Read tnova's builder sessions and cart additions as optional observations of eligible, analytics-permitted activity. Read confirmed paid box orders as a separate order measure. Dividing these headline counts does not establish a shopper conversion rate: they do not necessarily describe the same people or the same starting cohort.
This guide explains the implemented Data and orders report, not a claim that a merchant has achieved these results. Public installation remains unavailable. Development-store tests and unpublished previews are excluded from builder observations, so a successful test checkout should not be used to demonstrate a production analytics funnel. All numbers below are fictional.
Define each count before comparing it
Open Data and orders, choose the box filter and period, and record the displayed values with their labels. These counts answer different questions:
| Report label | What it represents | What it cannot establish |
|---|---|---|
| Consenting builder sessions observed | Recorded sessions initiated by selection activity for a live configuration when analytics processing is allowed | All product-page visits or unique shoppers |
| Cart additions observed after a client cart read | Recorded add observations associated with an eligible builder session and a cart operation | Every cart write, the number of boxes sold or completed checkout |
| Confirmed paid box orders in this period | Distinct orders with recorded box-sales facts in the selected reporting scope | Purchases attributed to the displayed builder sessions |
Opening a product page alone does not start a tnova builder observation. Selecting or changing items triggers the relevant activity. The browser session is specific to a box configuration; one shopper interacting with two configurations can therefore contribute to two sessions. Another session can begin after inactivity or a configuration-version change. This is not a cross-device customer count.
The add measure is also session-based. The implementation retains at most one add fact for an eligible builder session; repeated activity is not a raw count of every button click or every box unit. A cart containing two copies of a box is not evidence of two observed add sessions.
Keep analytics permission separate from purchase eligibility
tnova checks Shopify's analyticsProcessingAllowed() result before sending optional builder observations. Shopify's Customer Privacy API documentation explains that processing permission reflects merchant settings, visitor region and consent choices. A visible banner or a marketing choice alone does not prove that analytics processing is allowed.
If permission is unavailable or false, tnova does not record this optional activity. Its purchase flow does not wait for the analytics request. Browser capabilities, local storage access and successful delivery of the observation also affect whether activity reaches the report.
This means an order can exist without a corresponding observed builder session. It also means missing observations are not evidence that nobody tried the picker. Do not change a visitor's choice or weaken the store's privacy settings to make a dashboard look complete.
Shopify's customer and session discrepancy guide describes how privacy choices can reduce analytics coverage and why converted sessions need not equal orders. tnova's own observations have their own scope; they are not imported Shopify Online Store sessions.
Use a review sheet instead of inventing a conversion funnel
Suppose the following fictional report covers one configuration and one complete local day:
| Recorded measure | Count |
|---|---|
| Observed builder sessions | 40 |
| Observed cart-add sessions | 12 |
| Confirmed paid box orders | 5 |
The arithmetic 12 ÷ 40 equals 30%. But calling this “30% of shoppers added a box” changes sessions into people and assumes that the two event sets share a starting cohort. The arithmetic 5 ÷ 40 equals 12.5%, but the five paid orders are not established as purchases from those 40 sessions. Some buyers may have declined analytics, begun earlier or used a different session.
Use a literal note instead:
For the selected box and interval, the report recorded 40 builder starts, 12 cart-add observations and five confirmed paid box orders. These are separate measures; a linked shopper conversion rate has not been established.
Event dates add another complication. A builder session can begin before the interval and produce an add observation inside it. A purchase can be paid later still. The report counts facts by their own occurrence times, rather than showing a cohort of everyone who started during that day. A short interval can therefore show adds without a matching number of starts. Investigate the boundaries before concluding that tracking is broken.
For the UTC inputs, shop timezone and the separate sales, order-creation and refund date bases, use the CSV report guide. Do not mix its monetary totals into this activity comparison.
Investigate a missing count in the right order
Start with the environment. The public sample picker, unpublished previews and development-store activity are unsuitable for proving production observation counts. Keep functional acceptance testing separate; a test that confirms components and payment can pass while production observations remain empty.
For an authorized eligible environment, record the box identity and version, exact reporting interval, browser and observation time. Check the following without collecting customer identifiers:
- Scope: Is the report filtered to the configuration actually used? Did selection, add and payment occur inside the chosen boundaries?
- Permission: Is the store's privacy integration reporting the analytics decision through Shopify's API? Ask the implementation team to inspect the result if necessary.
- Activity: Did someone actually interact with the selection, rather than only load the page? Was a complete box confirmed in the same cart?
- Delivery: Could the browser use storage and the required browser APIs? Did an observation fail while the purchase itself succeeded?
- Order evidence: For a payment discrepancy, inspect Pending, Last order sync and the order's payment/integrity states. An analytics event is not payment evidence.
Do not create real purchases merely to populate a chart. Use the test-order audit for purchase verification and a focused support report for unresolved measurement differences. Never include session storage contents, cart tokens or credentials in a public report.
Compare periods only after recording measurement changes
Keep a small change log beside any comparison: configuration versions, assortment changes, theme/cart setup, privacy integration changes and reporting boundaries. Compare the same box scope and full-day intervals. A count difference can suggest a question to investigate; it does not isolate the effect of a new heading or assortment.
There is also a current Shopify-specific comparison boundary. Shopify documents a session measurement rollout from September 21–23, 2026, including updated session handling and default filtering of identified bots. It recommends treating this as a measurement change when comparing session-based metrics across the rollout. A conversion-rate change around that boundary does not by itself demonstrate changed buying behavior.
That Shopify update does not redefine tnova's separately recorded builder events. Keep each system's metric name and source on the review sheet. Use confirmed order evidence for what was purchased, observed activity for what was observed, and an explicit unresolved note when the connection between them is unknown.
About this guide: Prepared with AI assistance and checked against tnova's browser observation, analytics and reporting implementation and the official Shopify sources linked here on October 18, 2026. Examples are illustrative; no customer results, conversion uplift or analytics coverage guarantee is claimed.
See a gift box in action
Try the sample picker with fictional products. It creates no cart or order.
Try the box builder