Analytics definitions

The partner app's overview shows each store what shoppers did with its products in Leitagu: how often they were shown, opened, tried in a room, kept, saved and followed to the store's webshop. This page defines every number, says when and where each event is recorded and how duplicates are avoided, and lists what is not measured. Stores only ever see totals, never individual shoppers. Today all the events come from example products and test use, because no real store is connected yet.

#Where stores see the numbers

• Overview (Ülevaade) in the partner app: the totals for a period, the change from the previous period, a daily chart, the path from impression to store visit, the most shown products, where products were shown, data quality and the state of the data connections.
• Products (Tooted): impressions and store visits per product over the last 30 days.
• A product's page: all six counts for that product over the last 30 days, and a daily chart.
• The Leitagu team sees impressions and store visits per store over the last 30 days in the admin app (Stores), and store visits across all stores on the admin overview.

#The metrics

Apart from searches, shoppers and the two rates, every metric counts events: one shopper doing the same thing twice can count twice, within the rules below.

#When each event is recorded

Every event stores the product, the product's store (at the time of the event), the event type and the time. Where known it also stores the chat, the shopper's account id, and for impressions whether the product was shown in results or in suggestions. Events for product ids Leitagu doesn't know are dropped.

#Impressions

• What counts. When a chat turn ends with a result list or suggestions, the server compares the products shown, in order, with the list the chat showed before. If they differ, it records one impression for every product in the new list.
• Each product counts once per list. A turn that produces exactly the same list in the same order (for example a refinement that changes nothing) adds no impressions. A changed order, such as switching to "Cheapest first", is a new list.
• The whole list counts. A result list holds every product that passes the shopper's filters, plus up to three near misses. An impression means the product was in the list, not that the shopper scrolled to it.
• Context. Each impression is marked as results (Otsingutulemused) or suggestions ("What should I add?").
• Not counted: reloading a chat, the favourites page, and anything shown in the admin or partner apps.

#Opens and previews

• Opens. Clicking a product card opens its details and records an open.
• Previews. If a room is linked, the same click also previews the product in the room and records a preview. Browsing through the results with ‹ and › in the room panel records a preview for each product reached. The automatic preview of the best match when new results appear is not counted.
• Deduplication. The browser records each product's open and preview at most once per result list. A new list starts afresh, and so does reloading the page.
• Batching. The browser sends events 1.5 seconds after the first event of a batch; later events join that batch without delaying it. Anything still waiting is sent when the page is closed or left.
• Server checks. /api/events accepts only opens and previews, from a signed-in shopper, at most 20 events per request and 300 per shopper per hour. Events over the hourly budget are dropped silently. The budget is kept in memory, so with several server instances each counts separately. A chat id is kept only if the chat belongs to that shopper.

#Keeps and favourites

• Keep. Recorded each time a shopper keeps a product in a room. Removing it and keeping it again counts again. Keeps carry no chat id.
• Favourite. Recorded when a product is added to favourites. Saving a product that is already saved does not count; removing it and saving it again does.

#Store visits

• What counts. Every "Open in store" (Ava poes) link in the shop goes through /go/<product>: on product cards in a chat or in favourites, and on kept products in the room editor. The server records a store visit and then redirects to the product's page, or to the store's homepage if the product has no valid link. If neither is a web address, the link answers "not found" and no visit is recorded.
• Not counted: the preview card in the partner app links straight to the store, so a store checking its own products doesn't add visits.
• Who counts. Signed-in shoppers are recorded with their account id. Requests without a session count too, with no account id.
• Once per 30 minutes. A visit counts once per shopper and product within 30 minutes, so double clicks and reloads don't add up. Signed-in shoppers are checked against the visits already recorded. Requests without a session are told apart by a hash of their address and browser, kept only in the server's memory for 30 minutes and never stored.
• Not counted, but still redirected: requests marked as a prefetch or preview (Sec-Purpose, Purpose), requests without a browser identification, and known crawlers and link-preview fetchers (search engines, Slack, WhatsApp, Facebook and similar).

#Periods and comparisons

• Periods. The overview offers the last 7, 30 or 90 days, with 30 as the default. A period is a rolling window: from exactly 7, 30 or 90 days before now, up to now.
• Comparison. Each total is compared with the period of the same length just before it, shown as a percentage up (▲) or down (▼). If the previous period had none and this one has some, it says "new". If both are zero, it shows "—".
• Days. The daily chart groups events by calendar day in Estonian time (Europe/Tallinn). Because the period starts at the current time of day, the first and last days are partial. The chart switches between impressions, opens and store visits, and "Show as a table" lists all six counts per day.
• Product numbers on the Products page and on a product's page always cover the last 30 days.

#The funnel

"From impression to store visit" (Teekond näitamisest poodi) shows five bars for the period: impressions, opens, tried in a room, kept in a room and store visits.

• Each bar is a count of events, not of distinct shoppers.
• The steps are not strictly nested. A shopper can open a product without a room linked (no preview), or visit the store from their favourites without opening the product in this period. A later step can therefore occasionally be larger than an earlier one.

#Most shown products and where they were shown

• Most shown products (Enim näidatud tooted): the store's ten products with the most impressions in the period, with their impressions, opens, keeps, store visits and visit rate. A product deleted since then is listed by its id.
• Where your products were shown (Kus su tooted näha olid): impressions split by context (search results or "What should I add?" suggestions) and by product category, largest first, up to eight rows. The category is the product's current category, including a correction made in the partner app, not the category at the time of the impression.

#Data quality

The overview's data quality box (Andmete kvaliteet) counts the store's products, whatever their source:

Each count links to the matching filter on the Products page. Why missing dimensions hide a product, and how to fix the data, is in the partner integrations guide.

The overview also lists each data connection with the result and time of its last sync. When all of a store's products are example data, a banner says so.

#Privacy

• Stores see only totals: counts per store, per product, per day, per context and per category. They never see who did something, which chat it was in, or what else a shopper searched for.
• What we store. Events keep the shopper's account id and the chat id so that distinct shoppers and distinct searches can be counted. They are never shown to stores. The overview shows only how many different signed-in shoppers there were (Ostjaid).
• Inside Leitagu. The admin app also shows events only as totals: store visits overall and per product, and impressions and store visits per store.
• Account deletion. When an account is deleted, its chats, rooms and favourites go with it. Its events stay in the stores' totals, but their link to the account is removed.

#What is not measured

• Purchases in the store, or anything else that happens on the store's website after a store visit. Leitagu adds no tracking or affiliate parameters to the link.
• Revenue, basket value or conversion rates.
• Whether a product was actually seen on screen. An impression means the product was in the list.
• Time spent, scrolling, or which details the shopper read.
• Distinct shoppers per metric. Only the overall number of shoppers is shown.
• Shoppers' feedback on results (thumbs up or down, "did you find something?"). It is planned, not built.
• Signed-out browsing. The shop needs an account, so every event except store visits comes from signed-in shoppers.

#Data quality caveats

• No real traffic yet. Until stores connect and the shop opens to the public, the numbers come from example products, the Leitagu team and tests.
• Everyone counts, including Leitagu staff and test accounts. There is no filter for internal use; known crawlers are left out of store visits only.
• Signed-out repeats. Visits without a session are de-duplicated in each server's memory, so with several server instances, or after a restart, a repeat can count again.
• Opens and previews depend on the browser. Events still waiting when the browser crashes or loses its connection are lost. Ad blockers or privacy tools that block /api/events would stop them too.
• Impressions depend on list length. A broad search that matches many products produces many impressions, so impressions are best compared within a store over time.

#Related pages

• Partner integrations guide
• Why join Leitagu
• Platform architecture
• Glossary