# Car Parts Price Comparator — Monetization Analysis (POC, Stage A)

**Status:** Draft v1 · 2026-07-11
**Companion documents:** `FUNCTIONAL-SPEC.md` (what the product does), `TECHNICAL-SPEC.md` (how it's built).
**Scope of this document:** How — and whether — this product makes money. This is a strategy/economics analysis, not an implementation plan. No revenue feature is built or committed by this document.

> **Supersession note (2026-07-16):** The product no longer records searches or clickouts and no longer decorates outbound URLs for attribution. Measurement-dependent proposals below would require a new, separately approved privacy decision.

---

## 1. The core problem, stated plainly

The comparator currently scrapes 5 Latvian stores (Partsale, XPARTS, EOLTAS, Carparts, Handler) and sends each of them **free, high-purchase-intent referral traffic** via the `/out` click-through. Every buyer we forward is a buyer they acquire at zero marketing cost.

This creates the central tension of the whole business:

> **A store that already receives our traffic for free has no reason to start paying for it.**

Any monetization model that asks the stores we already feed to "pay for clicks" is dead on arrival. This is the free-rider problem, and it is the single most important fact about this product's economics. Everything below is a way of working around it — or an honest admission of where it can't be worked around.

---

## 2. The distinction that unlocks the conversation: CPC vs. CPA

The naive model is **CPC** (cost per click): the store pays every time we send a visitor. Against a store that already gets those visitors free, CPC is unsellable. We should not pursue it as a starting model.

The workable model is **CPA** (cost per acquisition / affiliate / revenue share): the store pays a percentage **only on a sale that actually closed and is attributable to us**.

Why CPA survives the free-rider objection where CPC doesn't:

| | CPC | CPA / affiliate |
|---|---|---|
| Store pays for… | every click | only completed, attributed sales |
| Store's risk | pays for clicks that never convert | zero — pays only out of realized revenue |
| Objection strength | fatal ("I already get these clicks free") | weaker ("prove the sales are incremental and I'll share a cut") |
| Industry precedent | rare in this vertical | universal — Autodoc et al. run it today |

CPA reframes the pitch from *"pay for traffic you already get"* (refused) to *"give me a revenue share on the buyers I can prove I sent you"* (the normal, boring deal the entire affiliate industry runs on). Autodoc itself pays 4–10% on this basis across Europe.

**Decision:** if we monetize the storefronts at all, it is via CPA/affiliate, never CPC.

---

## 3. The leverage problem is really a timing problem

CPA weakens the free-rider objection but doesn't erase it. A store can still say: *"You're already sending me these buyers for free — why would I now share 5%?"*

The honest answer: **our leverage is a function of audience size, and early on we have none.** This is the universal price-comparator bootstrap. idealo, Geizhals, Skroutz, and Google Shopping all:

1. gave the comparison away **for free** (scraping / feeds),
2. thereby became a **traffic source retailers genuinely cared about**, and
3. **only then** monetized.

The incentive for a store to pay does not exist until we are material to its revenue. **We cannot monetize at step 1.** The sequence is fixed:

> Be useful and complete for free → become a real traffic source → *then* formalize CPA from a position of *"I sent you N attributable sales last month; let's put it on a contract."*

This is why the money question and the **≥30% click-through gate** (see `FUNCTIONAL-SPEC.md`) are the same question. Below that gate, there is no audience, no leverage, and nothing to price. Above it, both CPA and big-retailer affiliate become reachable. **Click-through is the asset everything else is priced off.**

---

## 4. The trap: never sell placement

The one thing stores would *eagerly* pay for is **ranking** — being shown first, or being flagged "recommended."

We must not sell it. For a "cheapest available" comparator, **neutral price-sorting is the entire reason users trust the results, and that trust is the entire reason the traffic exists.** The moment ranking is for sale:

- users stop trusting the order,
- the comparison stops being a comparison,
- the traffic we were going to monetize evaporates.

We would be destroying the asset in order to rent it. `TECHNICAL-SPEC.md` already commits to strict price-sort neutrality; this document reinforces it as a **revenue-protecting** constraint, not merely an ethical one.

**Rule:** paid placement, sponsored ranking, and "featured store" slots are permanently off the table. The only visual monetization that does not corrupt the ranking is a clearly-labelled ad unit *outside* the results list (see §5.4), and even that is low-value.

---

## 5. Revenue engines, ranked by fit

### 5.1 Affiliate revenue from large pan-EU retailers (best long-term engine — currently blocked)

Autodoc-class retailers have real affiliate programs, deep pockets, and standing CPA infrastructure (Awin, Tradedoubler, Webgains, Rakuten, etc.), paying **~8% new / ~4% returning customers, ~30-day cookie**.

The model: show these retailers in the comparison like any other store; when they **win on price**, the buyer clicks through our affiliate deep-link and we earn a share of the sale.

**Why it's clean:** neutrality is preserved — we only earn when the paying retailer is genuinely the cheapest, so our incentive and the user's incentive point the same way.

**Why it's capped:** we earn *only* when they win, which bounds revenue. That's acceptable; it's the price of keeping trust.

**Why it's blocked today (the critical gap):**
- **No Latvia/Baltics affiliate program exists** for Autodoc — its program runs in ~26 EU markets and LV/LT/EE are not among them, even though `autodoc.lv` is a live storefront.
- The **part-number product feeds** that comparison sites (idealo etc.) ingest live on a separate **CSS / comparison-shopping-partner track**, gated behind an approved business relationship and application — not a self-serve affiliate signup.
- Additionally, `autodoc.lv/robots.txt` disallows `/search*`, and `trodo.lv/robots.txt` disallows `/catalogsearch/*` — so these catalogs are unreachable by scraping regardless. The *only* clean way in is a sanctioned feed partnership.

**Status:** this is the engine we want, and it is gated on a business-development step (securing an LV-market feed/affiliate agreement), not an engineering step.

### 5.2 Formalized CPA with the local stores (viable, but only later)

Once we can show partsale/carparts/eoltas *"I sent you 400 attributable buyers last month, here's the tracking,"* a modest revenue share becomes an easy yes — because now it is **incremental, measured, and risk-free** for them.

**Precondition:** proven volume. This engine is unavailable until after the CTR gate is cleared and the `/out` measurement can quantify per-store attributed traffic. Our existing measurement plumbing (`searches` → `search_results` → `clickouts`, see `TECHNICAL-SPEC.md`) is exactly the evidence base such a pitch requires.

**Friction:** small LV stores may lack affiliate/tracking infrastructure, so deals may need bespoke click/conversion tracking — more relationship overhead per euro than the big-retailer engine.

### 5.3 B2B / licensing (adjacent, opportunistic)

The scraping-and-comparison engine is itself an asset. Possible: license the comparison tech / data to a media outlet, a large workshop chain, or a store that wants an on-site "compare our price vs. the market" widget. Not a POC priority; noted for completeness.

### 5.4 Display / banners (low value — deprioritize)

CPM display or house banners earn almost nothing on a low-traffic niche LV site and clutter the neutral UI the whole model depends on. If ever used, must sit **outside** the results list and never influence ordering. Not worth building until traffic is substantial, and possibly not even then.

### 5.5 Charging users (rejected)

A consumer subscription/paywall for a free-to-search utility in a small market kills adoption and contradicts the funnel that generates the traffic we monetize elsewhere. Rejected.

---

## 6. Summary comparison

| Engine | Payer | Neutrality-safe? | Available when? | Blocker |
|---|---|---|---|---|
| Big-retailer affiliate (§5.1) | Autodoc-class | ✅ (earn only when cheapest) | after LV feed deal | **No LV program / feed-partner track only** |
| Local-store CPA (§5.2) | scraped LV stores | ✅ | after CTR gate + volume | needs proven attributable volume; per-store tracking |
| B2B / licensing (§5.3) | third parties | ✅ | opportunistic | requires a buyer |
| Display/banners (§5.4) | ad networks | ⚠️ only outside results | after high traffic | low value, UI clutter |
| Sold placement | stores | ❌ **destroys the asset** | never | permanently rejected |
| CPC (§2) | scraped stores | n/a | never | free-rider problem |
| User paywall (§5.5) | users | n/a | never | kills adoption |

---

## 7. What if a store refuses to pay?

"Show them the data, they pay" is the weaker engine precisely because it *can* be refused. But the refusal scenario is far less threatening once the two types of store are separated — and where it does bite, there are answers.

### 7.1 The two cases behave completely differently

**Large pan-EU retailers (Autodoc-class): they cannot free-ride, because access *is* the payment.** These stores are unreachable by scraping (Cloudflare + `robots.txt` disallow their search, per §5.1). The *only* way their catalog enters the comparison is through their feed, and the feed is bundled with the affiliate/CSS commercial relationship. So "refusing to pay" simply means "not being listed" — their choice, their lost sales, not a free-ride. For the stores that would generate meaningful commission, the question *"what if they won't pay"* barely applies: **the data and the deal are the same transaction.**

**Small local LV stores: many will refuse — and that is fine.** You scrape these from public data; they cost almost nothing to serve; their presence makes the comparison *complete*, which builds the audience that makes the retailer engine valuable. **A free-riding local store is a loss-leader that improves the product for free.** You do not need it to pay, and trying to force it is fighting the wrong battle. The stores that *can* refuse are the ones you don't need; the stores you need can't refuse without removing themselves.

### 7.2 The only stick — and why you'll rarely use it

The sole leverage over a hold-out is de-listing / cutting its referral traffic. It is a poor instrument:

- **Credible only once you're material.** Threatening to withhold 5 sales/month is a joke; withholding 400 is not. Leverage tracks audience size — the same variable everything else depends on.
- **Self-harming.** Removing a store makes the comparison less complete → erodes the user trust that generates the traffic → erodes all leverage. It is mutually-assured-destruction, not a routine lever.
- **Neutrality blocks the soft version.** You cannot quietly bury a hold-out down the ranking; price-sort neutrality (§4) forbids it.

Conclusion: de-listing is a last resort, not a business model.

### 7.3 Plan B that sidesteps the fight entirely: sell the view, not the traffic

Scraping produces something a store cannot obtain merely by receiving your clicks: a live, part-level map of where it sits against every competitor. Stores routinely pay for competitive pricing intelligence. *"You're 12% above market on the 20 most-searched filters — here's the dashboard"* is a product they would buy, and it **dodges the free-rider problem entirely**, because the insight is not something they get free by being in your results. Same data asset, monetized from the other side. Kept in reserve as a revenue path that depends on no one paying for clicks.

### 7.4 The tail risk: "free public utility" is a liability, not a soft landing

If the retailer LV feed never opens, every local store free-rides, and the intelligence angle doesn't land, the residual is "an excellent free tool with no revenue." That is **not** a benign resting state — it carries two standing costs that no revenue covers.

**Infrastructure, and above all maintenance labour.** Server cost itself is minor — a Latvia-scale meta-search on a small VPS with the 15-minute cache runs in the low tens of euros a month; live lookups are latency-light and the cache absorbs repeat queries. The real, unavoidable opex is **human upkeep of the adapters**: any store can change its markup at any time (the reason *"fast adjustment when a store changes"* is the #1 design priority in `TECHNICAL-SPEC.md`), and that maintenance burden grows **linearly with store count**. A free tool with no revenue is therefore a **standing obligation of unpaid labour**, not a free asset — it bleeds time indefinitely, and the more stores you add to make it useful, the more it bleeds.

**A tip jar offsets the infra line — and only that line.** A voluntary "buy me a beer" button (Ko-fi / Buy Me a Coffee / PayPal.me / a Stripe payment link — all usable from Latvia, near-zero effort as a footer link) can plausibly cover the low-tens-of-euros infra cost if even a handful of the audience chips in, and it frames the project as a community hobby rather than a commercial operation. Its limits, stated honestly: (1) a car-parts comparator is an *infrequent, transactional* tool — people use it a few times a year and leave — which is the worst possible profile for donations, so conversion will be a fraction of a percent and the total small; (2) it does **nothing** for the two costs that actually matter — it will not fund the ongoing **maintenance labour** (a few beers doesn't buy hours of adapter-fixing) and it will not touch **legal exposure** (a C&D ends the project regardless of the jar's balance); (3) accepting money *at all*, even tips, slightly erodes the cleanest *"purely non-commercial"* legal line, since commercial character is a minor aggravating factor under the DB-Directive / unfair-competition analysis (negligible at hobby scale, but not literally zero). **Verdict: worth adding as a low-effort infra offset and hobby signal, but it is a cost-offset, not a revenue engine — it makes "free forever" stop bleeding *cash*, while it still bleeds *time* and still carries the legal tail below.**

**Legal exposure, with nothing to fund a defence.** The design already minimises this — on-demand meta-search rather than bulk catalog copying (limits EU Database Directive / *sui generis* exposure), no persistent catalog beyond the short cache, delist-on-request, `robots.txt` honoured (we backed off Trodo/Autodoc search for exactly this reason), nominative use of store names for comparison, and anonymous measurement (no personal data → low GDPR surface). But exposure is not zero, and the realistic threat is **not a lawsuit — it's a cease-and-desist letter.** For a solo operator, even a letter you would ultimately win against is expensive and stressful to handle. **With revenue, legal is a cost of doing business; with zero revenue, a single C&D can end the project regardless of merit.** More stores = more counterparties who might send one. That asymmetry — *survivable with revenue, existential without* — is the crux.

**What this means.** In the no-revenue scenario the residual value is not the tool but the **audience** — as an acquisition target, a wedge into a market where feeds exist, or a B2B/licensing play (§5.3). And if none of those materialise, the honest move is to **sunset the service rather than run a costly, legally-exposed free utility indefinitely.** "Free forever" is a slow bleed of money, time, and risk. Naming that plainly is the point of this section: **monetization is not optional flavour on top of a happy free tool — it is what converts a standing liability into a going concern.**

---

## 8. Conclusion and recommended sequence

The money does **not** come from charging the stores we scrape for clicks — the free-rider problem makes that impossible. It comes from **attributable sales**, and it only switches on **after** we have become a traffic source worth attributing.

Therefore the monetization roadmap is not a pricing exercise right now; it is a **validation** exercise:

1. **Prove the click-through (≥30% gate).** This is the asset. No leverage exists below it. *(engineering + real-user test — the current focus)*
2. **Quantify per-store attributed traffic** using the existing `/out` measurement, so we can later say "N sales/month" with evidence. *(already plumbed)*
3. **Pursue the big-retailer LV feed/affiliate deal (§5.1)** — the clean, neutrality-safe engine — as a business-development track, in parallel. Its blocker is a partnership, not code.
4. **Formalize local-store CPA (§5.2)** only once volume is provable.
5. **Set a go/no-go, not a drift-into-free-forever.** If the CTR gate fails, or no revenue engine opens within a defined window, treat that as a decision point — pivot to the audience-as-asset or intelligence plays (§7.3–7.4), or **sunset**. A free tool left running with no revenue is a standing infra/labour cost and an unfunded legal exposure (§7.4), not a neutral default.

**One-line takeaway:** *Don't sell clicks; earn on attributed sales — and you can't earn on anything until the click-through gate proves there's an audience to attribute. The money question and the CTR question are the same question.*