Yes, that is a credible strategy. It turns the product into a two-layer funnel:

```text
Hosted web: open stores, easy adoption, broad reach
                ↓ proves demand and click volume
Native apps: extended store coverage, more committed users
                ↓ proves demand for closed stores
Closed-store feed/affiliate partnerships
                ↓ legitimacy + recognizable retailers
Open-store commercial conversion
```

Two adjustments matter:

1. This reduces legal exposure; it does not eliminate it. Native access to closed stores is still software we distribute and maintain.
2. “Partner or you’re out” should be a published commercial transition policy, not an improvised threat after giving a store free traffic.

## 1. The product structure

### Hosted web version

The website includes only stores that are reachable without:

- authentication;
- CAPTCHA solving;
- Cloudflare challenge bypass;
- stealth browser modifications;
- proxy or identity rotation;
- access after an explicit block.

This is the approachable product:

- open a URL;
- enter a part number;
- compare results;
- click through to a retailer.

Because the hosted version is centrally operated, we remain responsible for its fetching. It should therefore stay with the conservative adapters.

### Desktop and Android versions

The native editions provide “extended coverage”:

- open stores;
- stores that require a normal browser session;
- stores where the user may need to complete a challenge themselves;
- potentially twice as many stores.

The native application performs those searches from the user’s device and connection. That materially reduces central scraping and infrastructure risk. It is also easier to explain as a tool operated by the user.

It is not a complete legal shield. We still distribute the adapters, choose the targets, and benefit commercially. I would preserve these rules:

- No automated CAPTCHA solver.
- No fingerprint spoofing.
- No rotating proxies.
- No credential or authorization bypass.
- A challenge is completed by the actual user in a visible browser.
- Disable a store after an explicit objection pending review.
- Do not update the adapter to defeat a new target-specific block.

That gives us a defensible distinction between a user-controlled browser tool and a centrally operated evasion service.

## 2. Click measurement

Reintroducing click measurement makes sense now because it has a specific commercial purpose. The previous generic analytics system was rightly removed; this would be a much narrower system.

### Hosted web

Outbound links can use:

```text
/out?store=handler&url=<validated destination>
```

The server records a click and immediately redirects. It should not create a persistent visitor profile.

### Native applications

When the user opens a retailer result:

1. The application sends a small click event to our server.
2. It opens the original retailer URL directly.
3. Telemetry failure never prevents the link from opening.
4. The user can disable measurement in Settings.

The first-run notice should be direct:

> Help us prove that comparison shopping sends customers to retailers. The app reports anonymous totals when you open a retailer offer. It does not report your part number, browsing activity, or identity. You can disable this at any time.

I would use prominent notification plus an immediately available opt-out. Explicit opt-in is more privacy-conservative but will substantially undercount traffic.

### What an event should contain

A minimal event can contain:

```json
{
  "event": "retailer_click",
  "store": "handler",
  "surface": "android",
  "resultPosition": 2,
  "occurredAt": "2026-07-22T14:00:00Z",
  "eventId": "short-lived-random-id"
}
```

The event ID exists only to prevent duplicate submissions and should expire quickly.

Do not send:

- the searched part number;
- the destination URL if it contains the query;
- device advertising ID;
- stable installation ID;
- account identity;
- precise location;
- browser fingerprint;
- historical search identifier.

The server will inevitably see an IP during transmission. It should not place the raw IP in the analytics record. Ordinary short-lived security logs should be documented separately.

This provides store-level click counts without building user profiles.

### What we can truthfully claim

Before integrating with a retailer, we can prove:

- result impressions;
- outbound clicks;
- click-through rate;
- traffic split between web, desktop, and Android;
- general demand for broader store coverage.

We cannot yet prove:

- completed purchases;
- revenue sent to the store;
- conversion rate;
- incremental customers;
- basket value.

So the pitch must say “qualified outbound visits,” not “sales” or “customers acquired.” Sales attribution becomes available only after the retailer supplies an affiliate link, postback, coupon, or conversion report.

## 3. Approaching closed stores

Once the numbers are meaningful, the closed-store pitch becomes:

> During the last 90 days, our comparator generated 18,400 retailer clickouts. Users of our desktop and Android editions opened your offers 1,250 times despite your catalogue not being available in our accessible web version. Competing retailers received 7,800 web clickouts.
>
> We would like to include you properly in all editions using an authorised product feed or API. Ranking remains price-based. We propose CPA, so you pay only for attributed purchases.

The strongest evidence package would include:

- monthly active users by product surface;
- total searches;
- results-page-to-retailer CTR;
- clickouts by retailer;
- native demand for the closed retailer;
- web traffic currently going to competitors;
- geography, only if collected in a sufficiently coarse and privacy-safe way;
- measurement methodology and its limitations.

The pitch is not “allow us to scrape you.” It is:

> Demand already exists. Give us an authorised feed and we can expose you to the more accessible web audience as well.

That converts access from a legal/engineering obstacle into part of the commercial transaction.

## 4. What closed stores receive

A formal partner should get:

- placement in hosted web, desktop, and Android;
- feed-backed prices and availability;
- approved logo and product assets;
- reliable deep links;
- partner reporting;
- conversion attribution;
- a correction and escalation channel;
- feed-health diagnostics.

They should not receive:

- better organic ranking merely because they pay;
- the ability to suppress cheaper competitors;
- undisclosed sponsored positioning;
- access to identifiable user search history.

Ranking should continue to be based on published factors such as price, availability, delivery information, and match quality.

## 5. Converting the original open stores

Your leverage improves once one or more large retailers are participating:

- the product looks commercially established;
- coverage no longer depends entirely on the original open stores;
- we have real traffic statistics;
- we can offer an existing attribution mechanism;
- the threat of losing the comparator’s traffic is credible.

However, I would establish the transition policy before—or at least early in—the pilot:

> Retailer inclusion is free during the market-validation period. Once the service reaches the published commercial threshold, continued inclusion may require a data licence and commercial agreement. Participation does not influence organic ranking.

Then the later conversation is not “pay us because we already scraped you.” It becomes:

> During the pilot we sent you 3,400 qualified outbound visits at no charge. The service is now moving from validation to commercial operation. We would like to continue including you under one of the following arrangements.

Offer two practical options:

1. **CPA partnership**
   They pay only for attributed completed sales.

2. **Fixed data/inclusion agreement**
   Useful for stores without affiliate infrastructure. They provide permission and possibly a feed; we charge a predictable monthly amount.

A third outcome is removal:

> If neither arrangement is suitable, we will stop displaying your offers when the pilot ends.

That is a normal commercial boundary if applied consistently and communicated professionally. Avoid language suggesting reputational consequences, degraded ranking, or punishment.

## 6. Should non-paying stores really be removed?

This is the main product tradeoff.

Removing a good store makes the comparator less complete. Users may discover that the supposedly “best” price excludes retailers unwilling to pay. If many stores refuse, leverage and product value collapse together.

There are two viable policies.

### Strict partner directory

After the pilot, only authorised commercial partners appear.

Advantages:

- clean legal posture;
- no permanent free-rider problem;
- reliable feeds;
- straightforward business model.

Disadvantages:

- fewer stores;
- potential pay-to-play perception;
- results may not represent the whole market.

The UI must then say “Compare participating retailers,” not “Compare the Latvian market.”

### Free basic listing plus paid partnership

Public facts remain available as a basic listing, while partners receive:

- feed-backed inclusion;
- better freshness;
- approved assets;
- web and native availability;
- richer stock/delivery information;
- reporting and conversion integration;
- a verified-retailer designation.

Payment must still not buy organic rank.

This protects consumer completeness, but some stores may continue accepting free traffic indefinitely. CPA remains sellable only if we can prove attributable sales and offer advantages they cannot obtain from a basic listing.

My preference is a hybrid sunset policy:

- During validation: all safely reachable open stores are free.
- After reaching the commercial threshold: invitation to become a licensed partner.
- Stores declining the agreement retain only a minimal factual listing for a limited transition period.
- After that period, we either remove them or retain a permanently limited tier according to a rule published for every retailer.

Decide the final branch before negotiations begin. Never threaten removal unless we are genuinely willing to lose that store.

## 7. Commercial threshold

Do not approach stores after an arbitrary date. Trigger the transition when the evidence is persuasive—for example:

- sustained monthly search volume;
- meaningful store-level outbound clicks;
- healthy result-to-click CTR;
- repeat usage;
- at least one closed retailer showing measurable native demand;
- enough traffic that a plausible CPA conversion produces worthwhile revenue.

The existing monetisation document used a 30% click-through gate. That may still be a useful product signal, but absolute traffic matters more in negotiation: 30% of 100 searches has little value; 15% of 100,000 searches does.

## 8. The legal positioning

This model gives us a much better narrative:

- Hosted service touches only openly reachable sources.
- Collection is query-driven, not a catalogue crawl.
- Results contain factual fields rather than copied creative content.
- Native extended coverage is user-operated.
- Measurement is narrow, disclosed, and disableable.
- No stable user profiles are created.
- Ranking is commercially neutral.
- Stores can correct information, opt out, or negotiate authorised access.
- Protected stores are ultimately moved to feed/API agreements.

Still, avoid describing the model internally or externally as “without legal stuff.” More accurately:

> It avoids the highest-risk central circumvention model and creates a controlled path toward authorised retailer relationships.

## Recommended sequence

1. Write a new measurement and retailer-participation specification before restoring the removed analytics code.
2. Launch hosted web with open-store adapters only.
3. Ship desktop and Android as clearly labelled extended-coverage editions.
4. Introduce privacy-minimal, disableable clickout reporting.
5. Publish the validation-period and future-participation policy.
6. Accumulate roughly 60–90 days of credible traffic.
7. Approach closed stores first for feed/API plus CPA.
8. Secure one or two anchor retailers.
9. Approach the original open stores with their traffic reports.
10. Convert them to CPA or fixed agreements, or apply the published removal/basic-listing policy.
11. Eventually replace every commercially important scraped adapter with an authorised feed.

This is substantially stronger than trying to operate a stealth-browser farm. The real asset becomes measured consumer demand, while the native editions act as the bridge that demonstrates demand for stores not yet available on the public web service.

<oai-mem-citation>
<citation_entries>
MEMORY.md:173-182|note=[Confirmed that prior generic measurement was deliberately removed and this proposal would reintroduce it as a new scoped requirement]
</citation_entries>
<rollout_ids>
019f6ac6-58d0-75f0-a7b9-d9e0a7889bd8
</rollout_ids>
</oai-mem-citation>


Yes, that is a credible strategy. It turns the product into a two-layer funnel:

```text
Hosted web: open stores, easy adoption, broad reach
                ↓ proves demand and click volume
Native apps: extended store coverage, more committed users
                ↓ proves demand for closed stores
Closed-store feed/affiliate partnerships
                ↓ legitimacy + recognizable retailers
Open-store commercial conversion
```

Two adjustments matter:

1. This reduces legal exposure; it does not eliminate it. Native access to closed stores is still software we distribute and maintain.
2. “Partner or you’re out” should be a published commercial transition policy, not an improvised threat after giving a store free traffic.

## 1. The product structure

### Hosted web version

The website includes only stores that are reachable without:

- authentication;
- CAPTCHA solving;
- Cloudflare challenge bypass;
- stealth browser modifications;
- proxy or identity rotation;
- access after an explicit block.

This is the approachable product:

- open a URL;
- enter a part number;
- compare results;
- click through to a retailer.

Because the hosted version is centrally operated, we remain responsible for its fetching. It should therefore stay with the conservative adapters.

### Desktop and Android versions

The native editions provide “extended coverage”:

- open stores;
- stores that require a normal browser session;
- stores where the user may need to complete a challenge themselves;
- potentially twice as many stores.

The native application performs those searches from the user’s device and connection. That materially reduces central scraping and infrastructure risk. It is also easier to explain as a tool operated by the user.

It is not a complete legal shield. We still distribute the adapters, choose the targets, and benefit commercially. I would preserve these rules:

- No automated CAPTCHA solver.
- No fingerprint spoofing.
- No rotating proxies.
- No credential or authorization bypass.
- A challenge is completed by the actual user in a visible browser.
- Disable a store after an explicit objection pending review.
- Do not update the adapter to defeat a new target-specific block.

That gives us a defensible distinction between a user-controlled browser tool and a centrally operated evasion service.

## 2. Click measurement

Reintroducing click measurement makes sense now because it has a specific commercial purpose. The previous generic analytics system was rightly removed; this would be a much narrower system.

### Hosted web

Outbound links can use:

```text
/out?store=handler&url=<validated destination>
```

The server records a click and immediately redirects. It should not create a persistent visitor profile.

### Native applications

When the user opens a retailer result:

1. The application sends a small click event to our server.
2. It opens the original retailer URL directly.
3. Telemetry failure never prevents the link from opening.
4. The user can disable measurement in Settings.

The first-run notice should be direct:

> Help us prove that comparison shopping sends customers to retailers. The app reports anonymous totals when you open a retailer offer. It does not report your part number, browsing activity, or identity. You can disable this at any time.

I would use prominent notification plus an immediately available opt-out. Explicit opt-in is more privacy-conservative but will substantially undercount traffic.

### What an event should contain

A minimal event can contain:

```json
{
  "event": "retailer_click",
  "store": "handler",
  "surface": "android",
  "resultPosition": 2,
  "occurredAt": "2026-07-22T14:00:00Z",
  "eventId": "short-lived-random-id"
}
```

The event ID exists only to prevent duplicate submissions and should expire quickly.

Do not send:

- the searched part number;
- the destination URL if it contains the query;
- device advertising ID;
- stable installation ID;
- account identity;
- precise location;
- browser fingerprint;
- historical search identifier.

The server will inevitably see an IP during transmission. It should not place the raw IP in the analytics record. Ordinary short-lived security logs should be documented separately.

This provides store-level click counts without building user profiles.

### What we can truthfully claim

Before integrating with a retailer, we can prove:

- result impressions;
- outbound clicks;
- click-through rate;
- traffic split between web, desktop, and Android;
- general demand for broader store coverage.

We cannot yet prove:

- completed purchases;
- revenue sent to the store;
- conversion rate;
- incremental customers;
- basket value.

So the pitch must say “qualified outbound visits,” not “sales” or “customers acquired.” Sales attribution becomes available only after the retailer supplies an affiliate link, postback, coupon, or conversion report.

## 3. Approaching closed stores

Once the numbers are meaningful, the closed-store pitch becomes:

> During the last 90 days, our comparator generated 18,400 retailer clickouts. Users of our desktop and Android editions opened your offers 1,250 times despite your catalogue not being available in our accessible web version. Competing retailers received 7,800 web clickouts.
>
> We would like to include you properly in all editions using an authorised product feed or API. Ranking remains price-based. We propose CPA, so you pay only for attributed purchases.

The strongest evidence package would include:

- monthly active users by product surface;
- total searches;
- results-page-to-retailer CTR;
- clickouts by retailer;
- native demand for the closed retailer;
- web traffic currently going to competitors;
- geography, only if collected in a sufficiently coarse and privacy-safe way;
- measurement methodology and its limitations.

The pitch is not “allow us to scrape you.” It is:

> Demand already exists. Give us an authorised feed and we can expose you to the more accessible web audience as well.

That converts access from a legal/engineering obstacle into part of the commercial transaction.

## 4. What closed stores receive

A formal partner should get:

- placement in hosted web, desktop, and Android;
- feed-backed prices and availability;
- approved logo and product assets;
- reliable deep links;
- partner reporting;
- conversion attribution;
- a correction and escalation channel;
- feed-health diagnostics.

They should not receive:

- better organic ranking merely because they pay;
- the ability to suppress cheaper competitors;
- undisclosed sponsored positioning;
- access to identifiable user search history.

Ranking should continue to be based on published factors such as price, availability, delivery information, and match quality.

## 5. Converting the original open stores

Your leverage improves once one or more large retailers are participating:

- the product looks commercially established;
- coverage no longer depends entirely on the original open stores;
- we have real traffic statistics;
- we can offer an existing attribution mechanism;
- the threat of losing the comparator’s traffic is credible.

However, I would establish the transition policy before—or at least early in—the pilot:

> Retailer inclusion is free during the market-validation period. Once the service reaches the published commercial threshold, continued inclusion may require a data licence and commercial agreement. Participation does not influence organic ranking.

Then the later conversation is not “pay us because we already scraped you.” It becomes:

> During the pilot we sent you 3,400 qualified outbound visits at no charge. The service is now moving from validation to commercial operation. We would like to continue including you under one of the following arrangements.

Offer two practical options:

1. **CPA partnership**
   They pay only for attributed completed sales.

2. **Fixed data/inclusion agreement**
   Useful for stores without affiliate infrastructure. They provide permission and possibly a feed; we charge a predictable monthly amount.

A third outcome is removal:

> If neither arrangement is suitable, we will stop displaying your offers when the pilot ends.

That is a normal commercial boundary if applied consistently and communicated professionally. Avoid language suggesting reputational consequences, degraded ranking, or punishment.

## 6. Should non-paying stores really be removed?

This is the main product tradeoff.

Removing a good store makes the comparator less complete. Users may discover that the supposedly “best” price excludes retailers unwilling to pay. If many stores refuse, leverage and product value collapse together.

There are two viable policies.

### Strict partner directory

After the pilot, only authorised commercial partners appear.

Advantages:

- clean legal posture;
- no permanent free-rider problem;
- reliable feeds;
- straightforward business model.

Disadvantages:

- fewer stores;
- potential pay-to-play perception;
- results may not represent the whole market.

The UI must then say “Compare participating retailers,” not “Compare the Latvian market.”

### Free basic listing plus paid partnership

Public facts remain available as a basic listing, while partners receive:

- feed-backed inclusion;
- better freshness;
- approved assets;
- web and native availability;
- richer stock/delivery information;
- reporting and conversion integration;
- a verified-retailer designation.

Payment must still not buy organic rank.

This protects consumer completeness, but some stores may continue accepting free traffic indefinitely. CPA remains sellable only if we can prove attributable sales and offer advantages they cannot obtain from a basic listing.

My preference is a hybrid sunset policy:

- During validation: all safely reachable open stores are free.
- After reaching the commercial threshold: invitation to become a licensed partner.
- Stores declining the agreement retain only a minimal factual listing for a limited transition period.
- After that period, we either remove them or retain a permanently limited tier according to a rule published for every retailer.

Decide the final branch before negotiations begin. Never threaten removal unless we are genuinely willing to lose that store.

## 7. Commercial threshold

Do not approach stores after an arbitrary date. Trigger the transition when the evidence is persuasive—for example:

- sustained monthly search volume;
- meaningful store-level outbound clicks;
- healthy result-to-click CTR;
- repeat usage;
- at least one closed retailer showing measurable native demand;
- enough traffic that a plausible CPA conversion produces worthwhile revenue.

The existing monetisation document used a 30% click-through gate. That may still be a useful product signal, but absolute traffic matters more in negotiation: 30% of 100 searches has little value; 15% of 100,000 searches does.

## 8. The legal positioning

This model gives us a much better narrative:

- Hosted service touches only openly reachable sources.
- Collection is query-driven, not a catalogue crawl.
- Results contain factual fields rather than copied creative content.
- Native extended coverage is user-operated.
- Measurement is narrow, disclosed, and disableable.
- No stable user profiles are created.
- Ranking is commercially neutral.
- Stores can correct information, opt out, or negotiate authorised access.
- Protected stores are ultimately moved to feed/API agreements.

Still, avoid describing the model internally or externally as “without legal stuff.” More accurately:

> It avoids the highest-risk central circumvention model and creates a controlled path toward authorised retailer relationships.

## Recommended sequence

1. Write a new measurement and retailer-participation specification before restoring the removed analytics code.
2. Launch hosted web with open-store adapters only.
3. Ship desktop and Android as clearly labelled extended-coverage editions.
4. Introduce privacy-minimal, disableable clickout reporting.
5. Publish the validation-period and future-participation policy.
6. Accumulate roughly 60–90 days of credible traffic.
7. Approach closed stores first for feed/API plus CPA.
8. Secure one or two anchor retailers.
9. Approach the original open stores with their traffic reports.
10. Convert them to CPA or fixed agreements, or apply the published removal/basic-listing policy.
11. Eventually replace every commercially important scraped adapter with an authorised feed.

This is substantially stronger than trying to operate a stealth-browser farm. The real asset becomes measured consumer demand, while the native editions act as the bridge that demonstrates demand for stores not yet available on the public web service.