Tikra help

How the 97 % check and the 12-hour guarantee work

Names in bold such as Home, Orders, Platforms, Events, Incidents, Billing and Help are pages and buttons of the Tikra app. You open it from Apps in your Shopify admin.

Every hour Tikra checks that each platform got at least 97 % of the orders it should get in the last 24 hours. If a platform falls below that, Tikra opens an incident and aims to fix it within 12 hours. If the fix takes longer, you get one month free. The check and the guarantee start when your store has a plan: the free diagnosis sends no orders, so there is nothing to check.

What the check counts

The check looks at the online orders paid in the last 24 hours. Orders paid in the last 15 minutes are still being processed and are judged in a later run.

Orders to send are the ones a platform should get: online orders paid after you connected the platform, that the buyer's consent and your rules allow.

These orders are not counted in Orders to send, so they never lower the rate:

Reached means the platform accepted the order, or answered that it already had it. Everything else that was to be sent counts against the rate: orders still waiting, on hold, failed or not sent.

Google Analytics 4 does not confirm what it records. For it, Reached means Google received the order without an error. Its own reports show what it recorded. Orders that do not reach Google still count against its rate and can open an incident. See Connect Google Analytics 4.

Status is Reached divided by Orders to send over the last 24 hours. The target is 97 %: On target (97 % or more), Below target, or Incident open while an incident is open for the platform.

A platform needs at least 10 orders to send in the 24 hours before Tikra opens an incident for it. With fewer, Home shows Too few orders to judge, and no new incident opens. An incident that is already open is still judged with fewer orders: its clock runs while they do not arrive, and it closes once they do (see below).

Where you see it

What the hourly check fixes on its own

When a platform falls below 97 %

Tikra opens an incident for that platform. Home shows a banner, for example Meta is below target, with the time left on the clock. The Incidents page shows each incident with:

The 12-hour clock

The clock starts when the incident opens, or goes on from an earlier incident (see the paragraph after this list). It stops while the fix is not in our hands:

If the platform falls below 97 % again within 24 hours after an incident that closed within its 12 hours, the new incident's clock goes on from where the last one stopped. The incident card says so, with the date the first incident opened. After an incident that went over its 12 hours, with or without a free month, the next incident starts a new clock.

An incident opened because Meta counts more purchases than orders has its clock stopped from the start. See Turn off the store's own tracking.

When the incident closes

The incident closes on its own when the orders of the last 24 hours reach the platform again at 97 % or more, however few they are. It stays open while orders still do not arrive, even on a quiet day with only a few of them, and while no order comes in at all (the clock is stopped then). It moves to Resolved in the last 90 days with the time it took on the clock.

The free month

If an incident closes after more than 12 hours on the clock, the card says "This incident went over the 12-hour clock, so a credit is due." Tikra then applies the credit without a claim from you:

The credit needs a running subscription. If your store had no subscription yet when the incident closed (a trial without a subscription), Tikra applies the credit once you subscribe, if you do so within 30 days after the incident closed: a subscription that starts during your trial gets the 30-day trial extension, a later one the free month. When the credit is applied, the card says "A credit was applied on" and the date.

Each incident concerns one platform. The guarantee gives at most one free month per calendar month (UTC), counted by the day the incident closed. When several platforms fail at the same time, or a second incident goes over 12 hours in the same month, the fix and the re-sending are the same, and the card says that this month's free month was already given. The full rules are in section 8 of the Terms of Service.

Matching data on purchases

The Home page has a card called Matching data on purchases. For the last 7 days it shows the share of your paid online orders whose Purchase carried each identifier: email, phone, Meta browser ID, Meta click ID, another ad click ID, customer or visitor ID, IP address and browser user agent. Email, phone, IP address and user agent show what is stored on the order. Meta and Google use these to match a purchase to a person who saw an ad, so a low share is one reason their match quality can be low. We work it out from our own records of your orders. Test orders, cancelled orders and orders that are not online are left out, and the card waits until there are 20 orders.

Each identifier has three answers. Carried means it went with the Purchase. Not collected means the buyer did not clearly allow marketing (they said no, made no choice, or no signal reached us; on Shopify the pixel reads browser and click IDs only after the buyer allows marketing, in both modes; on WooCommerce in Standard mode no answer counts as allowed), so a browser, click or visitor ID is left out on purpose. That is not a fault. Missing means nothing reached us although the buyer had allowed it. An email or phone number is missing when the buyer gave none. Orders with no browser session on our side, for example ones added later, are left out of the browser and click ID rows. The Meta click ID and other ad click ID rows show only Carried, because only orders that came from an ad have one. The card may add a line, for example when the Meta browser ID is missing on many orders of buyers who allowed marketing. The free diagnosis keeps no buyer data, so the card starts once a plan runs.

Purchases Meta got only from the server

On Home, under the Meta numbers, you may see a line like "Tikra's server connection sent 37 purchases to Meta that Meta did not get from the browser". Meta counts every event it receives, so an order that reached Meta from both the browser and the server is counted in both. For each UTC day we take the server events minus the browser events (never below zero), and never more than the orders Tikra delivered that day. The number is that result added up over the last 7 full UTC days. This is an estimate, worked out day by day: it is too low when the browser reports orders that Tikra missed, and too high when another server sends to the same pixel. Meta keeps its statistics for 7 days, so we save them every day. If some days are not saved, the line says how many days it covers. If none are saved, the line says "not available" with the reason. The before and after report and the weekly report use the same method over their own days, so their numbers can differ from Home.

Read it with its limit. This is what Meta reports for purchases that came from our server with no browser event to match. It does not show that these purchases would have been lost, and it is not revenue. It is also not a count of the orders your browser missed. If another server connection, such as Stape, sends purchases to the same pixel, the number can be too high. When we see such a second sender, or while the platform is still in the check before sending, the number is not shown. If you run two Meta pixels, each has its own line with its label.

Still stuck? Email support@tikratracking.com with your store address and the date of the incident.