Atlas
Commerce data platform
Atlas is the foundation the other modules stand on, and it is useful on its own: every first-party signal you have, resolved into one profile per customer, queryable by anyone who can type a question.
- Prebuilt connectors for storefront, CRM, ads, support, and ops
- Identity resolution into single customer profiles with full journey history
- Ask for a chart, cohort, or breakdown conversationally — no SQL, no ticket to data
- One analytics layer shared by growth, support, and operations
Illustrative interface. Not real customer data.
The answer exists. It is in eight systems and a three-week queue.
Your storefront knows what they bought. Your helpdesk knows what went wrong. Your ad platform knows what you paid to acquire them. None of them know it is the same person, and the only people who can join it up are the two analysts everyone is queuing behind.
Atlas resolves identity across those systems into one profile with the full journey attached, then puts a plain-English interface on top of it. The question that used to be a ticket becomes a sentence.
What Atlas actually does.
Prebuilt connectors
Storefront, CRM, ads, support, payments, and ops — connected without a data engineering project per source.
Identity resolution
Email, phone, device, and order identifiers reconciled into one profile per customer, with the merge logic visible and adjustable.
Full journey history
Every touch in sequence: sessions, orders, tickets, calls, campaigns. The context every other module reads from.
Conversational analytics
Ask for a cohort, a breakdown, a chart, a comparison. Get the answer with the definition and the row count attached.
Shared metric definitions
One agreed definition of repeat rate, LTV, and contribution margin, used by every team and every module — so numbers stop disagreeing between decks.
Activation, not just reporting
Segments and profile attributes sync back out to your ESP, ad platforms, and the rest of the Novaleaf modules.
From connected to live.
Four stages. The first two are where the real work is; the rest is calibration.
Connect the sources
Authorise the systems you already run. Historical backfill plus ongoing sync, with the first pass usually surfacing data quality problems you did not know you had.
Resolve identity
Matching rules are proposed, you review and tune them, and the result is one profile per human rather than four rows per email address.
Agree the definitions
We write down what each core metric means, once. This is the least glamorous step and the one that determines whether anyone trusts the output.
Open it up
Growth, support, and ops query the same layer in plain English, with the analysts freed for the work that genuinely needs them.
Where teams point it first.
Cohort and retention analysis
Repeat behaviour by acquisition channel, first product, or discount depth — without waiting on a query.
True customer value
LTV net of returns, support cost, and discounting, rather than gross revenue with the awkward parts removed.
Support cost by product
Which SKUs generate the ticket volume — a question that usually requires joining two systems nobody has joined.
Shared operational reporting
One layer that growth, support, and operations all read from, so the weekly meeting stops arguing about whose number is right.
Questions you can put to it directly
Written as you would actually type them. Atlas returns the answer, the metric definition it used, and the population it ran on.
"Show repeat rate by first product, last 6 months"
Cohorts without a cohort tool.
"Which SKUs drive the most support tickets?"
A join across two systems that normally requires an analyst.
"LTV by channel, net of returns"
Using the definition your team agreed, not the platform default.
"Customers who bought twice then went quiet"
A segment, ready to sync to your ESP.
"Discount depth vs repeat purchase"
The question that decides next quarter's promo plan.
"What changed in refunds this month?"
Anomaly explanation, with the underlying orders listed.
Sits on top of the stack you run.
Prebuilt connectors for the common systems, and an integration path for the ones that are yours. Nothing here asks you to migrate.
Do not see yours? Ask us — most integrations are a connector, not a project.
Atlas, answered plainly.
Is this a replacement for our data warehouse?
No, and if you already have a well-run warehouse we will read from it rather than duplicate it. Atlas is the resolution and semantic layer plus the query interface — the part that turns storage into answers. Teams without a warehouse can use Atlas as their first one; teams with one keep it.
Can we trust a language model with our numbers?
Only if it is not inventing them, which is why every answer states the metric definition it used and the population it ran against, and why the definitions are agreed with you up front rather than inferred. If a question cannot be answered from the defined metrics, it says so instead of producing a plausible number.
How accurate is identity resolution?
It depends on your data, and you get to see and tune the matching rules rather than accept a black box. Deterministic matches on email, phone, and order ID do most of the work; probabilistic matching is optional and off by default, because a wrong merge is worse than a missed one.
Do we need Atlas to use the other modules?
Not strictly — each module can run against your existing systems directly. But Atlas is what makes them share one memory of the customer, so most teams that run two or more modules end up wanting it.
Bring a real workflow. We will show you Atlas running on it.
Thirty minutes, your data, no slideware. If it is not the right module for your bottleneck we will tell you which one is.