Consuming CCC

For anyone reading CCC data from outside the application: a dashboard, an export, a query, or a future automated consumer.

Errors here are silent. A join that multiplies order totals produces a believable number, not an error, which is why the conventions below are worth reading before the first query.

Start here

1. Dates, currency and signs. Three conventions, each with an exception that has caught someone.
2. Data model, grain and keys, so a join does not duplicate rows.
3. Consumption contracts, identity, dates, units, freshness.
4. Interfaces, what exists today and what it returns.

Four traps

One-to-many joins multiply totals. An order has many lines and many impacts. Joining to either and summing the order total counts it repeatedly.

Two date fields answer different questions. Transaction listings filter on creation date; customer sequence is ordered on transaction date. Pick deliberately.

Customer membership is reconstructed. Absorbed customer rows remain as pointers; follow mergedinto to the current group, and use the order assignment to resolve a later split. See merges and splits.

"New customers last month" is ambiguous until you state which life definition, which date basis and whether uncounted orders are excluded from the denominator too.

Historic figures move

A metric computed from CCC is a reconstruction from current understanding, not a snapshot of what was believed at the time. A customer merge moves history. If a figure must be stable, capture it when you publish it.

Later machine retrieval

Proposed capabilities records what a retrieval interface could offer. None of it is implemented. It exists so a future implementer can map a tool to a stable definition rather than guessing the business meaning.