Recipes

While there is no “funnel” field type, you don’t need one! A status column used in conjunction with gated dates gives you a funnel with dates that all make sense together.

1. Add a Category called status with the mix you want: 20% placed, 55% shipped, 25% delivered. You are stating the shape of the funnel directly, which is why this is a Category and not something cleverer.
2. Add created_at as a Date range, 90 days before the as-of date to today.
3. Add shipped_at, counting 1 to 3 days after this order’s created_at. Tick Only fill this in when status is shipped or delivered.
4. Add delivered_at, counting 1 to 5 days after shipped_at, gated on status being delivered alone.

Keep the gates consistent with the anchors. If a date counts from one that can be empty while it is filled in, those rows fall back to the as-of date, which is the one way this shape goes wrong.

Perfectly complete, evenly distributed data is the fastest way to make a demo look fake. A few settings fix it, and none of them takes longer than a few seconds.

1. Put % blank on the columns people genuinely leave empty: a phone number, a second address line, a note. 8 to 20% reads as real. Leave IDs, names and statuses alone.
2. Give every Number a shape. Order totals are “mostly small, a few large”; ages are an even spread. An even spread on money is the tell.
3. Set Spread on your main date to “toward recent”, because a growing business has more of everything lately.
4. Make one Category lopsided. Real status columns are not 33/33/33.

One thing to avoid: setting 20% blank on four separate address columns is not the same as 20% of rows having no address. It leaves most rows missing something and almost none missing everything. Use the address settings for that.

1. Add Place once. Its columns are unprefixed, so they read as the main address.
2. Add Place again. The second one pre-fills prefixed names like shipping_city. As always, you can rename the columns if you’d like.
3. Give each one its own country mix if they differ, for example billing 90% US and shipping worldwide.
4. Most orders ship to the billing address in real data. Set the shipping address’s How many rows have no address at all to 60%, and those rows come out with no shipping address, which most systems read as “same as billing”. The setting picks the rows at random, so there is nothing to choose.

The two addresses draw independently, so a row can be billed in Leeds and shipped to Bristol. Each is coherent on its own: the city, region and postal code always belong together.

Current dates are the point of this tool, so it is worth saying when you want the opposite. A screenshot in documentation, a test whose expected output is checked in, a demo you are preparing for a date in the future, a bug you are reproducing: all of those need the same dates every time.

1. In the As of section at the top, choose Fixed date and pick the day.
2. Save the model. The choice is saved with it, so every download from anywhere uses that day.

Everything else is unchanged: the same model and the same as-of day always produce the same rows, so the file is reproducible rather than merely dated. Switch back to Current date and the dates move again with nothing else disturbed.

1. Give customers.created_at a wide range in the past: 24 months before the as-of date to today.
2. Nest orders under customers.
3. Set orders.created_at to count from its customer’s created_at rather than from the as-of date: 0 days after, to today.

Because each date is anchored to its neighbor rather than to a calendar, the order survives any as-of date. Regenerate in a year and nothing has crossed over.

Nesting is for things that belong to one row, like a customer’s orders. A shared list is the opposite: one set of rows that lots of other rows point at, and that is what a Reference field is for.

1. Put the shared list in a table at the top level, not nested inside anything. Say products, with 120 rows, an ID, a name and a price.
2. In the table that needs to point at it, add a field and choose Reference, then pick that table. The column fills with real ids from it, so cart_items gets a product_id.
3. Set popularity to some are far more popular wherever real life is lopsided. A handful of products take most of the orders, and an even spread is the tell that data was generated.
4. Tick the box that stops a row pointing at the same one twice, where turning up twice in the same group makes no sense. Its label is built from your own tables, so it reads something like “Never point at the same product twice in the same cart”. The group is whatever the table sits inside, so with cart_items nested in carts, one cart cannot list the same product twice. On a table that sits at the top level there is no group, so it applies across the whole table.
5. Any number of tables can point at the same list, with nothing extra to set up. A returns table gets its own Reference to the same products.

Every id in those columns is a row that really exists, so the tables join. Note that prod_00074 appears twice in cart_items: no repeats applies within one group, not across the whole table, so a popular product still sells to plenty of people. Two limits worth knowing: the table you point at has to sit at the top level, and it needs an ID field for the column to hold.

Sometimes a column’s sensible values depend on a row in another table: a size of “512GB” on a t-shirt is the sort of thing people spot instantly. Bring the deciding value across as a column, then depend on it.

1. Make sure the deciding value is a field on the table you point at. A category on products, say, holding apparel, electronics and grocery.
2. In the table with the varying column, add a Reference to that table, which gives you its id column.
3. In the reference’s settings, tick the deciding column to bring it across too. You get product_category, holding each product’s real category.
4. On the varying column, tick Use different values depending on and choose that new column. You get a section per value: apparel gets S to XL, electronics gets 128GB to 1TB, grocery gets weights like 500g and 1kg. “Anything else” catches any value you add later.
5. If the deciding column has no place in your file, tick leave out of exports on it. It still decides the value; it just is not written out.

The sections read live from the field they came from, so renaming a value there relabels the section here rather than orphaning it. And the last step generalizes: any column you bring across can drive a rule and stay out of your file, which matters when you are seeding a schema with no room for extra columns.