3
8 Comments

You asked if the forecast actually changes decisions. Here's the answer, built in.

A few days ago, some of you pushed on something important: "connects the data" and "changes marketing decisions" are not the same claim, and I shouldn't let the first borrow credibility from the second without proof.

That distinction was worth taking seriously, so I built the answer directly into the product.

Now, every forecast saves as a dated snapshot instead of regenerating on every visit. And every time that forecast shapes a marketing decision, editing a plan, regenerating a tactic, that moment gets logged the instant it happens: yes, no, or a quick note, tied to the exact snapshot that was live at the time. Not something reconstructed from memory weeks later.

This is what "financially intelligent marketing" is supposed to mean. Your numbers don't just sit next to your marketing plan; they get to prove whether they actually moved it.

What's still ahead: comparing those logged decisions against what actually happened afterward. That needs more real usage before it means anything; this is where I'd genuinely appreciate help.

It's free right now. Try it and tell me what you find, especially whether the forecast changed a call you made; that's exactly the signal I'm trying to capture.

yfinanceai.com

on September 12, 2026
  1. 1

    The dated-snapshot-plus-logged-decision structure is basically variance analysis, just applied to marketing instead of budgets — forecast at a point in time, decision made off it, then compared to what actually happened. The hard part you're about to hit is the same one finance teams struggle with: timing lag between the decision and a clean, attributable outcome, especially when other variables move in between. Curious how you're planning to handle that noise once you start logging real comparisons — attribution window, confidence scoring, or something else?

  2. 1

    I like the approach of not just collecting data, but actually checking whether it influences decisions.

    1. 1

      That's the distinction that matters most here. Collecting data is easy, most tools stop there. Proving it actually changes a decision is the harder, more honest bar, and it's the one that makes the claim worth something.

  3. 1

    This is a solid response to that pushback — logging the decision at the moment it happens, tied to the exact snapshot, is the right fix. Reconstructed-from-memory data is basically useless for proving causality, so building that in from the start (rather than bolting it on later) will save you a lot of pain when you get to the comparison stage.
    The "compare logged decisions against what actually happened" piece is the hard part, and I think you already know that — curious how you're planning to handle the lag problem, since marketing decisions often take weeks/months to show up in results, and by then there's a lot of noise (seasonality, other campaigns, external factors) competing for credit.

    1. 1

      Appreciate that, and you're right, the lag problem is the real challenge here, not just building the comparison mechanism itself.

      Here's the plan: the first version won't try to isolate clean causality. It'll compare what the forecast predicted at decision time against what actually happened, directionally, not adjusted for seasonality or other campaigns yet. That's a deliberate choice, get the raw signal first, see what it actually shows with real data, before building a more sophisticated model to solve a noise problem I haven't confirmed exists yet at scale.

      If the noise does turn out to swamp the signal, that tells me something useful too, it means the "did this influence you" flag needs to capture more context at the moment of decision (what else was live, what else was running), not that attribution needs a heavier model bolted on after the fact.

      Curious how you've seen others handle this if you've come across a cleaner approach.

  4. 1

    Logging whether a forecast changed a decision is a much stronger signal than measuring engagement, but it still leaves the harder question open: do decisions influenced by the forecast actually outperform the alternatives? Is that comparison what you plan to establish next?

    1. 1

      Yes, that's exactly the next question, and the harder one. Right now I can show that a decision happened because of the forecast. What I can't yet show is whether that decision was actually better than what would've happened otherwise.

      That comparison needs two things I don't have enough of yet: real users making real decisions, and enough time passing to check the outcome against what was predicted. Building that measurement before there's data to run it against would just be guessing at what "outperform" even means in this context.

      Once there's a real sample of logged decisions, that's the next thing I want to build, comparing what the forecast said against what actually happened, not just whether someone said it influenced them.

      If you want to help generate that sample, it's free to try right now, yfinanceai.com. Genuinely curious what you'd find.

      1. 1

        That outcome-vs-forecast comparison is the more important test. If you’re open to it, what’s the best email to reach you on?