New customers in store analytics: reconciling the first order with your CRM
New customers in store analytics are not the same as new visitors or new CRM records. To obtain a reliable count of first-time customers, first define who counts as a customer and when a purchase is confirmed in your system of record. Then match orders to Google Analytics events using a stable identifier and classify discrepancies by cause.
This is a task for the e-commerce manager, analyst and integration developer. If you divide acquisition spending by an arbitrary “new” metric, a configuration change can look like an improvement in CAC — customer acquisition cost. The discussion below is not about choosing advertising channels, but about checking the denominator: who actually became a customer for the first time, and on what evidence.
First agree on whom the store considers a customer
Write down the definition before building the report. A working definition to test: a new customer is a unique customer whose earliest confirmed paid purchase falls within the reporting period. This is a business management rule, not a universal Google requirement. For cash on delivery, confirmation may mean receiving the funds rather than clicking the checkout button. For advance payment, you need to define separately how to handle a partial payment.
A “created” status does not prove payment, and a new contact record does not mean a new customer: it may be a duplicate created during an import. Agree on the rule across marketing, finance and operations, and name the person responsible for changes.
Also define the business scope: the website alone, all stores under the brand, or a separate legal entity. A customer who previously bought offline may be new to the website but not to the company. Do not mix these two metrics. The article on key business performance metrics provides the broader management context; here, the task is to check specific records.
What a first purchase actually means in Google Analytics
In the User acquisition report documentation, Google describes acquiring new users, not the arrival of first-time paying customers in your CRM. The first visit and first order may take place in different periods.
Do not substitute new users for customers
The New users metric is associated with the first interactions recorded by first_visit or first_open events. It does not confirm payment. According to the Monetization overview description, First time purchasers counts unique users from whom purchase was collected for the first time. This is closer to the question at hand, but Analytics' observation scope is not the same as your CRM's complete history.
Do not assume that a separate first_purchase web event is a mandatory standard: the metric described uses purchase. If you have a custom first_purchase event, check its specification: the name does not make it equivalent to the standard metric.
User identity has limits
Google allows activity to be linked through a User-ID created by the business. This does not automatically reconstruct every guest purchase or the history of the old website. The result depends on the implementation and reporting identity. Build the register of confirmed customers using agreed records from your business systems.
Assemble a minimum reconciliation register
Reconciling the first order with your CRM starts with two datasets: orders with payment statuses and available purchase records with transaction identifiers. Controlled exports are sufficient for a small store. A data warehouse is needed when the manual procedure can no longer be reproduced or there are many sources. A new dashboard without matching rules will not solve the problem.
| Criterion | What to record | How to check |
|---|---|---|
| Order key | Immutable order_id and corresponding transaction_id | One purchase does not receive different keys when the event is delivered again |
| Customer key | Internal customer_key and the basis for the link | A repeat payment by the same customer does not create a new customer |
| Purchase time | Payment confirmation time and time zone | Records at period boundaries fall within the same reporting period |
| Record eligibility | Payment, test, cancellation, full or partial refund | Every exclusion has a reason rather than simply disappearing from the total |
| Historical coverage | Start of reliable records and channels covered | “First in the database” is not presented as “first ever” |
Save the snapshot date, source, rule version and matching result. Do not overwrite the original exports: the total must be reproducible without hidden manual adjustments.
The algorithm is as follows: identify eligible purchases under the agreed rule; find the earliest one for each customer_key across the entire available history; only then select customers by reporting period. If you first limit the history to the current month, an existing customer making a repeat purchase will wrongly become new. Flag incomplete history separately instead of filling the gaps with guesses.
Link a guest to a customer without unsafe merging
A stable internal identifier can serve as the reference for a registered customer. For a guest, you need agreed matching rules within the store's secure environment. A verified contact detail may help establish a link, but a shared family email address or company phone number does not prove that orders belong to one person. A matching name or delivery address alone is not enough.
Keep the basis for the merge and the ability to undo it. Send doubtful pairs for review or leave them in an “identity unresolved” group. Forced merging can combine different people.
Customer identification requires clear boundaries between systems. Do not send email addresses, phone numbers or full names as User-ID, transaction_id or arbitrary event parameters. Check URLs and page titles for contact details from forms in accordance with Google's guidance on preventing PII. Keep the link between technical keys and contact details inside the controlled environment.
Hashing is not blanket permission to send contact details in ordinary purchase parameters. For this reconciliation, use order keys, not customers' contact details.
Classify discrepancies by cause instead of forcing the total to match
Match orders first, then count unique customers. The reconciliation report needs these groups: present in both sources; present only in the system of record; present only in Analytics; conflicting key; mismatched status or time. Assign a next action to each group. For example, a missing purchase requires checking event delivery, not automatically removing a paid customer from the CRM.
According to the transaction_id documentation, Analytics removes duplicate purchase events with the same identifier in web streams. The key must be unique to the order, nonempty and not shared by different customers. However, transaction deduplication is not customer deduplication: different purchases by one person naturally have different keys.
Cancellations and refunds need a separate policy
An unpaid cancelled order does not satisfy the proposed rule for a confirmed purchase. A full refund after payment is a different case: payment did take place, but the business may separately count customers who kept their purchases. Show these metrics side by side if needed, and do not change the definition retroactively without a note. A partial refund is likewise not the same as no purchase.
The refund event with the corresponding transaction_id is provided for in Google's e-commerce instructions. But do not assume that sending it automatically recalculates your CRM cohort of first-time customers according to the required rule. That is separate logic. For cash on delivery, late confirmations and refunds, agree on a repeat snapshot date and label preliminary results.
Hypothetical example: a guest returns on another device
Imagine someone bought as a guest, then later created an account on another device and paid for another order. If the store has a verified link between the guest purchase and the profile, the internal customer_key remains the same. The earliest eligible purchase belongs to the previous period, so the customer does not become new in the current one.
Without that link, do not “correct” the result based on a similar surname: flag the uncertainty. If the first order was not paid for, it does not become the first eligible purchase. If it was paid for and subsequently refunded, apply the refund policy rather than the rule for cancellation before payment.
This is a hypothetical scenario, not a GL.ua case study. To use the result in CAC, align costs, the period and channel coverage. An overall customer register does not, by itself, provide a correct CAC for an individual campaign.
Check acceptance criteria before launching the report
The analyst tests the pilot together with the developer and the person responsible for sales. Readiness means explaining discrepancies, not forcing Analytics and the CRM to agree.
- Test a new paying customer and a repeat customer. Only the first receives the flag for a new purchase in the period in the register.
- Repeat the confirmation upload and delivery of the same event. The order retains its key, and the internal total does not increase.
- Check a guest, an account login and a doubtful contact match. Each case shows the basis for the link or explicit uncertainty.
- Work through payment, unpaid cancellation, and partial and full refunds. Results follow the written rules, not the current status label.
- Match records at the period boundary and a late payment confirmation. Document the time zone, snapshot date and recalculation.
- Review event parameters, URLs and logs for leaked contact details. Save anonymized evidence of the check and assign a monitoring owner.
Separately test a scenario where purchase did not arrive because of data collection restrictions. A paying customer must not disappear from the system-of-record metric. Record the missing analytics event as an observation gap, without trying to circumvent the user's choice. Repeat acceptance tests after changes to payments, the CRM or the tag container.
Timelines, cost and the limits of useful precision
Timelines depend on the availability of history, the quality of statuses and identity rules. The stages are: source inventory, metric dictionary, trial reconciliation, integration fixes and a repeat snapshot. Give a calendar estimate after the inventory: an old import may require more work than configuring purchase.
Break down costs into history analysis and cleaning, CRM data exchange improvements, event configuration, testing, storage and regular checks. If controlled exports already produce reproducible results, a complex profile unification platform may be unnecessary.
The main risks are incomplete history, incorrectly merging people and hidden methodological changes. It is better to report the first known purchase honestly than to call it the first ever. A reliable total comes with an explanation and someone responsible for exceptions.
If the problem lies in data exchange between the website, payments and the CRM, discuss online store development with CRM and integrations with GL.ua (Glyanets). Prepare a description of the flow and anonymized examples of discrepancies to assess the required improvements and acceptance criteria.
Just one step to your perfect website
