Before

Agree the objective, the model and the holdout with Analytics before the first send goes out.

Fill it in

Eight fields, one page. If a field is hard to fill in, that is the field most worth arguing about now.

After

Report against the plan you agreed, including the holdout gap, not just the platform's own numbers.

Filled example, a Q4 lapsed-customer email campaign. The attribution and naming reasoning is Insyt's own; the campaign's own figures are illustrative.

1. Objective (the business number)

Add €40,000 of incremental Q4 revenue from lapsed customers (no order in 90+ days), without discounting below 15% off.

2. Primary metric and its definition

Incremental orders from the lapsed segment, at full attribution value. “Incremental” means orders that would not have happened without this campaign, not every order touched by it.

3. Guardrail metrics

4. Baseline and target

Baseline: Lapsed-segment orders in a comparable 4-week window with no campaign: 210 orders, €19,300.

Target: 520 orders, €41,000 in the 4-week flight, the €40k objective plus a small buffer.

5. Attribution model agreed, and why

Linear, across every marketing touch in the 30 days before purchase.

6. Incrementality method

Regional holdout: email suppressed for 20% of the lapsed segment, matched by region and order history. · holdout 20% · 4 weeks, matching the flight

7. UTM taxonomy applied

Rule: channel_campaign_audience, all lower case, hyphens inside each word, underscores between the three parts.
This campaign: email_2026-q4-lapsed-winback_lapsed90

8. Reporting date and owner

Read-out: 2 weeks after flight close (allows late/returned orders to settle)
Owner: Lifecycle Marketing Lead; holdout design signed off by Analytics before send

Before

Agree the five fields and the fixed lists before the first campaign, not after names have drifted.

Fill it in

Check any tag you already have against the convention, and log who owns changes to it.

After

Build every tagged link from the pick-list, never by typing, that is what keeps the convention alive.

Filled example, the check-table rows are Insyt's own Name the UTMs exercise, exactly as it presents them.

The five fields

Medium: fixed list of eight

cpc, paid-social, organic-social, email, affiliate, referral, display, direct

Forbidden in any field

• Spaces (use a hyphen inside a word instead)
• Upper case letters (report tools often treat Email and email as different campaigns)
• Inconsistent punctuation inside a value. The five UTM fields are separate URL query parameters joined with &, not underscores.
• Punctuation that breaks a URL: & ? # % + and accented characters

One complete tagged link

Put each field in its own URL parameter; do not combine source, medium and audience into utm_campaign.

https://example.org/offer?utm_source=linkedin&utm_medium=paid-social&utm_campaign=2026-q4-lapsed-winback&utm_content=banner-a&utm_term=lapsed90

Check against the approved lists and URL-encode values where required. Never include personal data in UTM parameters.

Governance

One journey, Five models

How the €120 splits

What each model rewards

None of the five prove a sale wouldn't have happened anyway. Attribution assigns credit among the channels that were present; it doesn't test what happens when a channel is absent. That's incrementality.

Incrementality: What none of them measure

An illustrative example, not from the practice page above (which raises the question but doesn't run the numbers).

A holdout test on branded search: run it in half your regions, withhold it in the other half, compare conversion rate.

lift = conversion rate (exposed) − conversion rate (holdout) = 4.0% − 3.4% = 0.6 points of lift on the exposed group.

The GA4 note

GA4's default reporting model is data-driven attribution. But Google deprecated first-click, linear, time-decay and position-based as selectable models in GA4 and Google Ads in November 2023, only data-driven and two last-click variants (paid-and-organic, and Google-paid-channels) remain inside GA4 itself. The four rule-based models above are still standard industry concepts and still worth calculating by hand or in another tool, but they are no longer GA4 report settings you can just switch between.

What they reveal

Filings, job adverts and pricing pages reveal most of a competitor's strategy.

Source every line

"How we know" and a date, per fact, not a single blended impression.

Stay falsifiable

Write what would change your view, so the profile isn't fixed the day you wrote it.

Filled example, built from Insyt's own Read the Filing exercise figures.

Name

“Alta Sky Centre AS” (illustrative name for this filing-extract exercise, not a real company)

What they sell

Workflow software for mid-size logistics operators (illustrative).

To whom

Mid-size 3PLs and freight forwarders, sold direct (illustrative).

At what price

List: from €1,200/seat/year. Observed in a lost-deal interview: €950/seat/year at 40+ seats (illustrative).

Revenue and growth

People

Headcount rose 40% year-on-year. Of that growth: Engineering 62%, Sales 18%, Operations 4%, Admin 2%.

Strengths

• Heavy, sustained engineering investment (62% of headcount growth), suggests a real product roadmap, not just cost-cutting (source: filing extract).
• 30% gross margin, in line with mid-market B2B software norms (source: filing extract, computed).

Weaknesses

• Customer concentration risk, and rising: largest customer = 38% of revenue this year, up from 31% last year, with contract renewal due in the coming year (source: filing extract). This is the single biggest thing the filing reveals.
• The filing is silent on why customers choose them, on pricing by customer, and on product roadmap detail, those gaps have to be filled by reviews and lost-deal interviews, not the accounts (illustrative note, general to any filing).

Recent moves

40% headcount growth concentrated in engineering, consistent with a product push rather than a go-to-market push (source: filing extract).

How we know

What would change our view

If the largest-customer renewal is confirmed lost, or if next year's filing shows engineering headcount growth reversing, both would change this profile materially (illustrative).

Four methods, one product

Illustrative, worked on one product with a €30 unit cost, so the four methods can be compared side by side.

Five more formats

The discount break-even box

Every discount comes straight off margin, not off revenue. This site's own Set the Price exercise makes the point directly: cut price 10% at a 30% margin, and you need 50% more volume just to break even, because your margin per unit fell from 30 points to 20.

Volume increase needed to break even = discount % / (margin % - discount %)

Evidenced, Set the Price, round 1: a 10% price cut at a 30% margin needs a 50% volume increase to break even (10 / (30-10) = 50%).

Evidenced, Defend the Discount adds the other half of the picture: a 5% discount at a 25% margin removes a fifth of the profit on that deal. Never give a discount without getting something back: volume, term, payment terms or scope.

The van westendorp panel

Van Westendorp's Price Sensitivity Meter (1976) asks the same buyer four questions about one product, then reads the price range from where the answers cross.

Reading the range

Before

Agree the bands and approvers with sales leadership and finance, once, before the first exception request.

Fill it in

Four bands, an approver per band, what evidence is required, and the margin floor it protects.

After

Watch the weekly discount log for deals clustering just under a threshold, that is the policy being gamed, not followed.

Filled example, four bands, green to red, with the break-even arithmetic per band.

Before

Agree the criteria with sales and RevOps together, not written by one side and imposed on the other.

Fill it in

Entry and exit as observable facts, not feelings. "The economic buyer attended a meeting", not "feels warm".

After

Load it into the CRM as required fields per stage, so a deal cannot advance without the fact being true.

Filled example, six stages, criteria written as observable facts.

Lead

Entry

Contact has responded to outreach or a marketing offer

Exit

A discovery call is booked with a named contact

CRM fields

Source, contact name, company, company size

Probability

5%

Typical days

3

Owner

SDR

Qualified

Entry

Confirmed budget range and a named use case

Exit

A stakeholder beyond the first contact has joined a call

CRM fields

Budget range, use case, next step date

Probability

15%

Typical days

7

Owner

SDR, handing to AE

Discovery

Entry

The economic buyer has attended a meeting

Exit

Requirements document shared and agreed with the buyer

CRM fields

Economic buyer name, requirements doc link, competitor(s) named

Probability

30%

Typical days

14

Owner

AE

Proposal

Entry

Written proposal sent with pricing

Exit

Verbal commitment to proceed, pending contract

CRM fields

Proposal value, decision date, procurement process noted

Probability

55%

Typical days

12

Owner

AE

Negotiation

Entry

Contract redlines in progress

Exit

Signature received

CRM fields

Contract start date, signer name, discount level

Probability

80%

Typical days

20

Owner

AE, with deal desk

Closed Won

Entry

Signature received

Exit

Terminal stage, handover to Customer Success

CRM fields

Close reason code, contract value, start date

Probability

100%

Typical days

n/a

Owner

AE, handover to CS

Side a · the frameworks

One deal, scored three ways

€180,000 analytics platform renewal. The IT lead loves the product and says budget exists, but finance has not confirmed it. The economic buyer, the CFO, has not been met. Stated pain: month-end close takes nine days, target is five. Procurement will run a three-vendor comparison; the CFO signs anything over €100k. The IT lead is enthusiastic but has no budget authority of their own. The incumbent vendor's contract renews in March, which is forcing the decision now.

BANT

Verdict: Two of four known. Budget and authority both trace back to the same unconfirmed source, find out before investing more time.

What it leaves out: Budget-first ordering can drop a deal early just because finance hasn't been asked yet, even when the need is real and quantified, as here.

MEDDIC / MEDDPICC

Verdict: Four of eight known. The gaps cluster around the buying side: economic buyer, decision criteria and paper process are all still unknown.

What it leaves out: Eight elements to track is heavy for a small or fast-moving deal, teams often skip it below a deal-size threshold.

SPICED

Verdict: Three of five known. SPICED surfaces the same buying-side gaps as MEDDIC in fewer elements, but never asks about budget directly.

What it leaves out: No explicit budget element, a SPICED-qualified deal can still turn out to have no funding.

Scoring it

Score each element 0 (unknown), 1 (partially known) or 2 (confirmed). A deal is “qualified” once every element scores at least 1 and the buying-side gaps, economic buyer, decision criteria, champion, score 2.

Side b · score your own deal

Use the same three tables. Write what you know in the middle column, then mark each element known or a gap.

Before

Book the interview with the buyer who decided, not only the champion who is kind by nature.

Fill it in

Twelve questions, in order, one at a time. Leave silence after each; the real answer often comes second.

After

Code the real reason against the fixed list of seven, not the reason that was easiest to record at the time.

Filled example, the ask/don't-ask columns, and two real deals from Insyt's own Win or Loss? exercise.

Ask

1. Why did you start looking in the first place?
2. Who else did you consider?
3. What mattered most in the decision?
4. Where did we fall short?
5. What did the winner do that we didn't?
6. Was this decided on price, or on value?
7. Who actually made the final call?
8. What would have changed the outcome?
9. How was the buying process for you, working with us?
10. Would you consider us again in future?
11. If you could change one thing about how we sold to you, what would it be?
12. Can we quote what you've told us today?

Do not ask

• “Was it price?”Leads the witness to the easiest, laziest answer. Ask what mattered most instead, and let price come up on its own if it's real.
• “Didn't you like our product?”Invites a polite lie rather than the truth. Ask what the winner did differently.
• “Are you sure you made the right choice?”Defensive, and puts the buyer on the back foot. They will not open up after this.
• “What did we do wrong?”Too broad to answer well. Ask for the one thing they'd change, not an open-ended critique.
• “Would you switch back to us?”A hypothetical that costs nothing to answer kindly. Ask what would need to be true instead.
• Two questions in one, e.g. “what mattered most, and where did we fall short?”Compound questions get a half-answer to each half. Ask them one at a time and let each land.

Summary sheet: reason codes: PriceProduct fitRelationshipTimingIncumbentNo decisionProcess

Outcome

One measurable change at the top, not a feature.

Opportunities

Three to six customer needs found in research, not brainstormed ideas.

Solutions & tests

Two or three solutions per opportunity, each with a small test of its riskiest assumption.

Filled example, a retention tree, drawn from Insyt's own Framework Library.

Outcome

Raise week-4 retention from 34% to 40%

Opportunity 1

Users lose track of reports they've already built

Solution

A 'recent reports' shortcut on the home screen

Assumption test

A 5-user prototype test of the shortcut before building it

Opportunity 2

New users don't reach their first useful report before they stop coming back (illustrative)

Solution

A guided first-report template picked from their role (illustrative)

Assumption test

Time-to-first-report measured for 20 new signups against the current baseline (illustrative)

Solution

An in-app checklist for the three most common first reports (illustrative)

Assumption test

A/B the checklist against no checklist for one cohort week (illustrative)

Opportunity 3

Scheduled reports fail silently, so users assume the product stopped working (illustrative)

Solution

An email alert the moment a scheduled report fails (illustrative)

Assumption test

Ship the alert to a 10% holdout and compare week-4 retention (illustrative)

The outcome, at the top

The outcome sits at the top of the tree, and it is a measurable change in customer or business behaviour, never a feature. “Raise week-4 retention from 34% to 40%” is an outcome; “build a recent-reports shortcut” is not, that's a solution, three rows down.

Pick the North Star makes the same point from the metric side: a good outcome measure only rises when customers actually get value, and should be hard to game. Time-in-app can be inflated by making the product slower; a completed shared outcome usually can't be.

Opportunities, solutions, tests

Opportunities are customer needs, pain points or desires found in research, not brainstormed feature ideas. Aim for three to six per tree; more than that usually means the research wasn't synthesised enough.

Two or three solutions per opportunity, each a genuinely different way to address the same need, not variations of the same idea.

Every solution carries an assumption test: the smallest, fastest check of its riskiest assumption, before you commit to building it.

A worked tree

Scenario: A 200-person B2B software company selling data-analytics tooling to mid-size retailers.

Outcome

Raise week-4 retention from 34% to 40%

Evidenced

Opportunity 1, Users lose track of reports they've already built

Solution

A 'recent reports' shortcut on the home screen

Assumption test

A 5-user prototype test of the shortcut before building it

Illustrative

Opportunity 2, New users don't reach their first useful report before they stop coming back

Solution

A guided first-report template picked from their role

Assumption test

Time-to-first-report measured for 20 new signups against the current baseline

Solution

An in-app checklist for the three most common first reports

Assumption test

A/B the checklist against no checklist for one cohort week

Illustrative

Opportunity 3, Scheduled reports fail silently, so users assume the product stopped working

Solution

An email alert the moment a scheduled report fails

Assumption test

Ship the alert to a 10% holdout and compare week-4 retention

The outcome, Opportunity 1, its solution and its test are this site's own worked example (the Opportunity Solution Tree card in the Framework Library). Opportunities 2 and 3 are clearly-labelled illustrative additions for the same scenario, added here to show a fuller tree.

How to prune

• An opportunity that doesn't plausibly move the outcome doesn't stay on the tree.
• A solution with no assumption test doesn't stay on the tree.
• If two solutions test the same assumption, keep the cheaper test and drop the other until you know more.

Before you build: Test the assumption

Should You Ship It? is the test that follows an assumption test that went well: significance alone isn't enough to ship, because a barely-significant result and a tenth of the lift you needed is a result you should read carefully, not celebrate. Set your ship/iterate/stop thresholds before the test runs, not after you see the number.

How it feeds the experiment plan and the roadmap

Once a specific solution and its test are chosen and need a rigorous design, the tree feeds the Experiment Plan directly: the solution becomes the change under test, and the assumption becomes the hypothesis. The surviving branches, in priority order, feed the roadmap.

What it leaves out

• Delivery capacity, a well-formed tree can still describe more work than the team can deliver in the period.
• Dependencies between teams, the tree shows what's worth doing, not the sequence or handoffs needed to do it.