Include data deep dives so @markoivanik has to reply

Please respond to this so Drew has someone to talk to and leaves Eng alone.

Brands get your data cleaned up, even if you don’t use iris (you probably should) you are leaking CM. Like Peter Drucker said - you can't improve what you don't measure

Go add up your fivetran bill + dbt bill + snowflake bill, don’t even need to include Eng headcount. Then realize @markoivanik and crew did it better anyway

Iris is a complete, out of the box data warehouse and analytics platform, but our website used to only show like 5 connectors. @drewfallon12 finally let us update the site, only took 3 months

Took a lot for me to not steal this chart and post as my own when Drew shared internally. Great read and top of mind after my time at Gruns

I hate the new MLB playoff format, play 162 games and decide it on a best of 3 … but that Harper homer, baseball is pretty great

The number one thing brands ask me: How should my framework for LTV:CAC change once I’m selling in retail? It's easy when you're just on Shopify or TikTok Shop because the data is all there. Amazon changed their data model recently but you can still do this analysis. Retail is a totally different exercise. Typical Pattern: CAC goes down. A big Costco launch puts you in front of a ton of customers who have never seen your brand and the retailer is doing most of that acquisition work for you. You dont see it in your marketing spend but they are charging you for it in margin, so the cost quietly moves off your marketing line and into COGS. There are still marketing costs in retail, handing out samples on a Saturday costs money, so you still need a full view of the marketing costs too. LTV will probably drop too and is the bigger issue because the data isnt clear. A retail customer might be buying every three weeks with perfect loyalty and you'd have no idea. Syndicated and panel data take a swing at repeat behavior, and it's worth buying, but it's directional and expensive. Subscription brands generally get hit harder because some of your existing subscribers will start buying in store instead. That shows up in your data as churn when it's really a channel shift. Model retail repeat off whatever panel data you can get, then back-test it against the DTC cohorts you actually own to see if the shape is believable. It won't be exact, there are some assumptions you need to make based on your business, and the math can get a little funky. It also becomes more important to understand the halo effect of all of your marketing. A FB ad drives someone to Target, and someone who picked you up at Walmart goes to your site to learn more. Incrementality testing and MMM are huge here. Throw in unit economics / price pack architecture across sales channels, different expiration rules, logistics costs and retail gets really fun Tactically the ratio is still the thing to manage. If CAC drops further than measured LTV the ratio improved and you have room to spend more. Most brands see LTV falling, get nervous, pull back on the channel that just got cheaper.

The number one thing brands get wrong when building out the data team: the first hire The first data hire is the toughest one to nail - analyst, engineer, or generalist. I've seen it done wrong constantly, and been hired to fix it twice. The analyst is the tempting choice. Someone who can answer questions today, build the dashboard the board asked for, stop the CEO from pulling CSVs at 11pm. Six months later they're the fastest person alive at downloading spreadsheets, because nobody ever built the thing underneath it. So hire the engineer. Except now the engineer disappears into infra for six months, comes back with a beautiful data warehouse, and nobody noticed they were gone. Six months of no visible value is longer than most brands will tolerate for a data engineer you are paying at least $150k and usually longer than that persons political capital lasts. The job is actually one person doing both. An analyst who can engineer, or an engineer who can analyze. I don't think the starting side matters much. What matters is that the foundation gets built by someone who has to use it every week, because that's the only reliable way to find out whether the model is right. Pipeline week 1 > the CFO's margin question week 2 (or maybe month 2), using the thing you just built. The AI tilt: this got much easier. An analyst with Claude can stand up dbt models they couldn't have written alone. An engineer with Claude can write a real narrative around a number instead of handing over a table. The gap narrowed from both direction but still isnt closed. AI closes the syntax gap, not the judgment gap. Knowing a number is wrong before you send and can validate the solution it is still the main job. So the bad news: you're still kind of hiring for a unicorn, at a stage where unicorns have better offers. It is really hard to convince a world class engineer or data scientist to join your startup selling widgets on the TikTok.

One for the data nerds. Almost every brand runs A/B tests - install a shopify app, split traffic, wait a week, pick a winner based on cvr lift. The better tool from my experience is a “multi-armed bandit” and almost no one uses them. Let me explain. The name comes from slot machines, imagine you are standing in front of a row of slot machines (bandits who want to steal your money) and you have to choose which arm to pull. Each machine pays out some unknown amount at some unknown frequency. Your goal is to find out which machine to play and how often to keep checking the others. In MAB each variant being tested is a slot machine, and the traffic you send it is an arm pull. The quick version: MAB allocates traffic in proportion to each variant's probability of being the best one. You have 4 variants, each starts with 25% of traffic, a week later the leader is getting 60% because the algo is seeing better results. Losers get “starved” but never fully cut off. It explores and exploits at the same time, and most importantly it never stops running. A/B testing gives you a verdict about last month, then you adopt the winner and turn testing off, assuming November behaves like August. It is also susceptible to adopting false positives - you check the test day three, day five, call it when the bar turns green. Every peek is another shot at a false positive. Bandits don't have a stopping decision to corrupt. Caveats (really getting into the weeds): - vanilla Thompson sampling assumes stationary rewards. use a sliding window version so you notice a winner decaying. - More variants to test (arms) means slower convergence which can be brutal at low order volume. - Bandits are built to earn, not learn, so if the real question is "did free shipping change behavior" run a clean test. The catch few address: all of this optimizes conversion rate. Conversion rate is rarely the true objective. A variant lifts CVR on a discount, that cohort ends up with a higher return rate, the whole thing nets out worse. The reward function should be tied to contribution margin, with LTV as the check after the fact. Most testing tools can't do that because they don't have access to COGS and all of your other data.

Have you ever wondered why shopify & your P&L show different revenue numbers? Neither are wrong, they’re just…different - but because they’re different it can limit your use of AI. For example - you can, and should, calculate revenue 3 ways - using Order to Cash as a bridge. But you need to know each of these numbers along the way and train your ai agents to know the difference What is Order to Cash? It's the accounting process of reconciling orders to actual cash received. Revenue can be calculated in the following ways: 1. Operating. recognized when the order is placed. This is the number marketing celebrates and probably lives on your existing dashboards/reports. 2. Accounting (GAAP). recognized when the order is fulfilled, this is almost always when the order ships but there can be some nuance. Anything sitting at the warehouse waiting to be shipped out isn’t revenue yet. 3. Cash. recognized when the sales channel actually pays you. Shopify settles in days. Marketplaces settle on a cycle and hold a reserve. Wholesale settles on net terms, minus deductions you'll spend a quarter disputing. Illustrative numbers for a month with $1M in orders: - $1,000,000 orders placed - less $60,000 unshipped at cutoff → $940,000 accounting revenue - less ~$100,000 channel and payment fees - less ~$70,000 refunds and returns — and these hit this month's cash against last month's revenue - less chargebacks and retail deductions - less what's still in transit or reserve at cutoff You booked a million but you get paid a fraction of it in a different month. None of the these are wrong, they just answer different questions: - Operating revenue tells you about demand helps with optimizing marketing spend, offers, sales, etc. - Accounting revenue tells you about margin, fulfillment performance - Cash revenue tells you whether you can pay the bills. This one is usually the trickiest to automate, but unlocks accurate cash flow forecasting. Most brands don't discover this until they hire their first controller, usually the same week a lender asks why the bank statement doesn't match the P&L. The good news is that all of the data is available. Every brand should have visibility to all 3.

Alerts should be table stakes for brands, but rarely is. One reason is that it was a pain, weird config in a BI tool or hacking together a DB read to send a slack. Building alerts with natural language like this is really slick.

Who’s going to beanstalk? Come say hi if you see me and break me out of the shell, I’ll be the extreme introvert standing on the outskirts avoiding conversation

Everyone wants a 3.0 LTV:CAC, but no one actually knows how to calculate it. Let’s walk through how we calculated LTV and CAC at gruns - and it starts with the data Most brands will go and download an app off the shopify app store, maybe it plugs into amazon, and that app will give them a LTV calculation and a CAC calculation and they will take it at face value. They are paying anywhere from $500-$2,000/mo What they don’t realize is the $12,000+ per year app isnt giving them correct data. If it did, why would we have had an all star team of 10+ people across data at gruns if we could spend $12k for the same thing? It comes down to the data transformation process. Most brand owners will tell you they are data driven, but there is still a lot of education to be had on this side of the house. Its a ‘you dont know what you dont know’ situation. In order to accurately calculate LTV:CAC you need to decompose every shopify order and all of its components so you can calculate delivered gross margin. Shopify doesn’t even give you the proper net sales out of the box so you need to start there. Shopify does not give you GAAP net sales, but if you are ingesting data yourself it is straightforward Gross Sales + Shipping Income - discounts - refunds = Net Sales. Then you have to deal with gift cards (these are not revenue at time of purchase, only time of redemption), chargebacks, refund timing, gifting, employee orders, and cancelled orders. Luckily Shopify’s data model is pretty clean. Then do the same for Amazon, TikTok Shop, and your other sales channels. At this point you’ve calculated the proper net sales for every order you’ve ever had - now you can join your COGS, 3PL, and merchant costs to that exact order to get delivered gross profit. The Shopify stuff is easy, understanding ALL of the costs associated with an order is much more difficult and might require another dozen data pipelines to get correct. Shopify gives you a customer ID so you join all the orders from each customer ID, to get their total delivered gross profit. You should be able to pick any random customer from your customer list, and you should be able to pull up their LTV with gross profit from every order they’ve placed with you. With correct data infra you can also get LTV cuts at a bunch of interesting angles to optimize the business - by SKU, geo, etc. This requires real data infrastructure, not apps from the shopify store At that point, you just divide LTV by CAC and have confidence in your numbers

Things we got right at gruns #6 - BizOps I hated the BizOps title. It’s Strategy & Analytics. But we tried to hire an Analytics Associate and got nothing, switched it to BizOps and the resumes poured in. When we met with a new vendor or a new brand and had to do the uncomfortable intros I always unmuted and said “I lead Data, my job is to take credit for all the work these guys do”. Our BizOps team was absolutely world class. BizOps: - A centralized data team that was comfortable writing SQL and building with AI but could still build a financial model in Excel - think ex-banker types who are financially oriented but more entrenched in the data - P&L assignments with a company northstar. Each team member worked closely with a specific function but was still tied to the overall KPIs and OKRs for the company - Autonomous. The team ran our Monthly Business Reviews by partnering with their function, interpreting metrics > actions > measuring results. Along the way BizOps was running business case models to make sure decisions were profitable, building ad-hoc reports, maintaining our AI reporting portal, and even helping drive headcount planning. Once the foundational data is in place, every brand should build a BizOps team.

Things we got right at gruns #5 - The data stack…for now A managed data ingestion platform, dbt Cloud (big proponent of dbt and owning your transformation logic), and a BI tool can easily cost a brand at scale $125k+. We picked all of these tools for the same reason: ease of use and speed to value. Given where we were and how fast we were growing, they were the right decisions. They were not the cheapest ones, and they were probably not the optimal ones. Here's the part the vendors leave out. Buying the managed stack did not remove the team. We had 4+ engineers focused on data: 1. custom Python orchestrated on Airflow, for everything the connectors didn't cover. We had a big ETL budget and still needed engineers writing custom code. 2. Data modeling. Dbt is an amazing tool, but the tool runs the models, it doesn't know your business. There are some great open source packages out there for ecomm businesses but still had to to touch code for every model. 3. Building the reports. The opposite of dbt. Point to click BI tools are a pain, and at this point very antiquated. The contract we signed before I joined didn’t hold its weight by the time I left So six figures gets you managed pipes and you still have to build the layer that makes the numbers true, because that layer is your business and no vendor has it. That's the trade I'd make again, if I was in the same position. but the paradigm is shifting quickly. AI tools are quickly replacing the Modern Data Stack. A foundational data warehouse + semantic layer is still massively important, but how brands get there is evolving.

Things we got right at gruns #4 - Reporting & DKM Every morning we sent a report in Slack called DKM - Daily Key Metrics. We had a similar report emailed out at Tecovas. ~15 metrics, each at a daily, weekly and monthly grain, one for the company and one for every brand individually. It went to everyone, not just finance or leadership. CAC, rev by channel, fulfillment lead time, First Orders, CVR, and a dozen or so other metrics that the company ran on. Most brands have this as a dashboard nobody opens, our difference was push vs pull. If the number has to be pulled, it gets pulled when someone is already worried. If it gets pushed at 8am, everyone starts the day discussing the same reality. Three things made it work: 1. same grain every day - daily, wtd, mtd side by side, so you can tell a bad day from a bad trend. one bad day is noise, three is a decision 2. high visibility. You didnt need to bug the data team to know what CAC was or if fulfillment time was slipping, everyone could go view the same report with the agreed upon definitions 3. per brand, not just consolidated. consolidated numbers hide the brand that's quietly funding everyone else's CAC It also killed a meeting, nobody needs a Monday recap of numbers everyone already read on Friday. The hard part wasn’t building a fancy dashboard or report, it was the data underneath it. Nailing down the foundational data warehouse was what allowed all of the reporting and AI work to run smoothly, getting that right allowed the report to write itself. Get it wrong and you've automated a lie.