The owner of an online coffee store in Almaty compares five days before a tracking change with five days after. The report shows 90 orders instead of 60, and he messages you on WhatsApp: "Sales are up by half. We can increase the budget." You open the CRM: both periods hold 100 paid orders, the store's usual 20 a day, or about 140 a week. The store is not selling more. It has simply started to see what it was already selling. Raise the budget on the strength of that report and you spend more money with no better reason than before.
It is the same store as in the retention lesson: an order is 15,000 ₸, and 6,000 ₸ is left after the goods and delivery. We invented the reconciliation for this lesson, and all figures in the example are made up. Your work does not start with the report, though. It starts with the question you had in mind when you opened the article about analytics setup.
Five days before and five days after setup
| Orders | Before | After |
|---|---|---|
| Paid in CRM | 100 | 100 |
| Recorded in analytics | 60 | 90 |
Coverage changed for sales the store was already making.
Open an article with a task in mind
It is easy to spend an evening in Academia: read about a CRM, follow a link to events, then on to advertising. By morning you have three ideas and no decision. Come with a note from work instead, for example: "The CRM has paid orders I cannot find in the channel report." Now the article has a job: help you find why orders go missing and how to fix it.
A task needs a person waiting for the result and a decision they will make with it. At the store, the owner sets the ad budget, you reconcile orders, and the developer changes how events are sent. You can finish the reconciliation on your own; growing sales is different work, and not only yours. Say so to the owner up front. That way you agree on what he is paying you for, and a month later nobody asks you for revenue the reconciliation could never affect.
If you do not have a project, use the test site from the Start track. You can submit a form, trigger a form error and save screenshots. Note that the site is a test site. That data is enough for a case study about setup, and there is no point inventing revenue for someone else's business: the first client who reads it will ask where the numbers came from.
Put the test into four rows
HADI stands for Hypothesis, Action, Data, Insights. It is the order in which you move from a question to an answer. The card below describes a technical check: the result rests on scenarios anyone can repeat and on an order reconciliation. If you want to know how customer behaviour changed, you need an experiment plan.
| Step | What to record for the store |
|---|---|
| H, hypothesis | Some paid orders get lost on the way to analytics; first find what the missing ones have in common |
| A, action | Match orders by ID, reproduce the error you find and fix event delivery where it breaks |
| D, data | Orders marked paid in the CRM, events with the same IDs, missing orders, duplicates and amount mismatches |
| I, insight | Which scenarios are fixed, what is still unmatched and whether this report can support a budget decision |
"Install a new tool" does not belong in the first row: it names no cause. Say two orders are sent with the same ID. Move event delivery to a server and they will merge in exactly the same way. First find one order where you can show the ID changing or disappearing.
The card may change once you have read the article. You suspected a delivery failure and found something else: the CRM and the report use different time zones, so late payments slipped into the next day. Then the fix is the comparison period, and you may not need the technology from the article's headline.
Reconcile the same orders
The store's CRM holds created, paid, cancelled and refunded orders. For the reconciliation, take only paid orders, without cancellations or refunds, for one period, in one time zone and one currency. Then look up each payment in analytics by order ID. Totals will also match when gaps and duplicates have cancelled each other out, so you reconcile the list of IDs, not the total.
The working table has one row per order: ID, payment time, amount in the CRM, amount in analytics and the reason for any mismatch. Leave customer names and phone numbers out of the export: the reconciliation does not need them, and the table will be passed to the developer. Mark amount mismatches separately. An event may have arrived carrying the price of one item instead of the whole order.
Of 100 orders, 60 were found at first and 90 after the fix. If all matched IDs are unique, coverage rose from 60% to 90%, or by 30 percentage points. The relative increase is (90 - 60) / 60 = 50%. That is where the owner's "up by half" came from. The figure belongs next to measurement coverage, but CRM sales were 100 and are still 100.
For simplicity, let every order in the reconciliation cost 15,000 ₸. The CRM then holds 1,500,000 ₸ in revenue in each period. Analytics first shows 900,000 ₸, then 1,350,000 ₸. The 450,000 ₸ difference appeared in the report; no such money reached the store's account. The contribution from 100 orders did not change either: 600,000 ₸ before other costs.
Decide what finished means
For a fix to event collection, the schedule depends on the scenarios and on a check against production data. Before the work starts, list every payment method and the case where one event arrives twice. Name who owns the reconciliation, and agree what to do with any mismatches that remain. After the fix, go through the list again with the developer.
Our 90 matches leave ten missing orders. Sort them by cause: the order is still being processed, delivery failed, the ID differs, or no event was ever set up for that scenario. The work is finished when it meets the acceptance criterion you agreed in advance. A rate of 90% looking better than 60% does not close the task. If some orders stay outside analytics, describe that limit next to the report, so the owner does not mistake 90 for all sales.
Repeat purchases run on their own schedule. The store measures them within 60 days of the first payment. The reminder goes out 21 days after delivery, and the result waits until every participant's window has closed. In a week you will know whether the messages are being sent correctly, but the answer about 60-day repeat orders will not exist yet. That is why the timing of a retention test is worked out before launch.
Keep a record you can return to
A good reconciliation note fits into a paragraph: "There are 100 paid orders in each period. Analytics contains 60 and 90, with no duplicates among them. The delivery error in the documented scenario is fixed. We are investigating the ten remaining missing orders by ID. CRM revenue did not change." Attach the table and the steps that reproduce the error.
With that note, the owner knows what to do with the report. You keep working through the gaps, the developer gets cases he can reproduce, and the budget is discussed using spend, payments and contribution from the CRM. You will open the next article for the next open question and add its link to the same card.
Exercise: a card for your article
Choose one Academia article you need for a task you are working on. Write the problem in the client's words, the decision they will make and the four HADI rows. Name the data source, what exactly you count (an order, a lead, a payment), the schedule and the completion criterion. If it is a test project, say so in the first row.
Then answer the owner from the opening and his "Sales are up by half. We can increase the budget." Your reply needs both analytics revenue figures, the CRM figure and the next step.
Analytics used to show 900,000 ₸ and now shows 1,350,000 ₸, while the CRM holds 1,500,000 ₸ for each period. Sales did not grow; tracking did. It is too early to decide on the budget from this data: the example gives neither spend nor a link between orders and channels. The next step on the card is to investigate the ten missing orders and match confirmed payments with spend. You could write to the owner along these lines: "Orders are the same; analytics now just sees 90 of the 100. Let's talk about the budget once I have matched payments with ads by channel." That is a next step another person can check and accept.