One wall of love for everyone is a wall for nobody.
An agency on LinkedIn, a developer from Hacker News, and a price-shopping founder from Product Hunt all land on /pricing — and you show all three the same five testimonials. The agency wants to see other agencies. The developer wants the API quote. The founder wants to know it pays back.
Contextual Match uses bounded request context to choose a proof filter — without maintaining a separate widget for every campaign or page.
Read. Match. Serve.
Matching is resolved server-side before the widget renders. The browser still makes the normal widget-data request.
Read
The loader sends bounded page path, referrer domain, UTM source, medium, campaign and content, plus optional page tags with the widget-data request.
Match
Enabled rules are evaluated by priority. The first matching rule applies its configured proof filters to the eligible testimonial pool.
AND path = "/pricing"
THEN match tag AGENCY
Serve
The server returns the selected proof and match metadata. The async runtime then renders the response inside the widget's Shadow DOM.
Four context groups. No identity profile required.
Rules use the request context implemented by the public widget API. Language can also guide translation, but is not a match condition.
Context chooses the rule. Filters choose the proof.
Each contextual rule reuses the widget's implemented auto-sync filters, including tags and optional Proof Intelligence fields.
Priority rules. Explicit fallback.
Enabled rules run in priority order. If the contextual pool is too small, choose the base auto-sync pool or keep the contextual result without overriding it.
One <script> tag. Four shipped variants.
All four visitors hit the same URL with the same widget. The widget renders the proof their context calls for.
Not a feature flag. The delivery layer.
Contextual Match combines widget selection filters, Proof Intelligence enrichment, and Proof Impact evidence without claiming unsupported integrations.