Data delivered to the SaaS's customers

Write the transformation once with the tenant id as a column and read the tenant list from a configuration table (id, display name, destination layer, start date, active sources, parameters such as window and rate). A new customer is one row in that table. Copies are only justified when the customer has its own source that doesn't exist for the others, and even then they call the same calculation.

On Nekt, permissions are granted per layer. Deliver each customer in its own layer (or its own destination) and never in a shared table filtered only at read time. The consolidated table with every tenant stays in an internal layer, visible only to the SaaS team.

Tables that have the tenant id are filtered directly. Child tables without that column (items, messages, insights) come in through the foreign key of their parent table; reference tables come in with only the rows the tenant's records use. Check that every copied table has a path to the tenant.

Keep a closed list of columns that never leave: client_secret, access_token, refresh_token, passwords, API keys and integration credentials. Exclude them from every delivered table, including those from standard connectors, such as the Stripe payment intent's client_secret.

Revenue attributed to a message, campaign or automation counts only orders from the same end customer placed after the send and within the agreed window (one real case uses 3 days). Each order is attributed to a single send, the most recent one before it. Amounts in cents are divided by 100 once.

Some order integrations send only the date, with time 00:00:00. For each tenant, look at the last three orders: if all have zeroed hour, minute and second, treat the field as a date and compare the window in days; otherwise, as a timestamp. Store the decision in the tenant's configuration.

If an input is missing (rate not registered, meter offline, stalled integration), the result is null with a reason column, never zero. Distinguish a data error from a deliberate decision: a customer who only contracted kWh metering has null savings in reais and no alert, not an incomplete-rate alert.

Days with no reading can be filled with the average for the same weekday in the nearest real period, but the row carries a flag (measured or projected). Never use a fixed fill value. The savings baseline is the per-weekday average over the monitoring window before the automation; if operations change (for example, the number of devices), open a new baseline regime with a cutoff date.

To prove a feature's impact, split the customer's items into with and without it based on the list the customer maintains, and compare views, cart, purchase and revenue over the same period. The match is by item id; with no id, by a name that starts with the registered name, keeping a single match, the most specific one (longest name).

When the product writes its own derived tables (prefixes such as dw_ or dwt_) alongside the application tables, use the application tables, which are the source of truth. Record in the context document the tables whose names mislead (for example, a table called credit that stores charges), filter soft deletes (deletedAt null) and drop from the report any metric whose status is never filled in at the source.