You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Partner placement is split into three separate decisions:
4
+
5
+
-**Eligibility:** whether a partner can appear for a surface, category, library, feature, or user context.
6
+
-**Tier:** the partner's commercial/display tier, which controls visual treatment and relative access to surfaces.
7
+
-**Order:** the sequence used inside a surface once eligible partners are known.
8
+
9
+
The order policy should be explicit per surface. Avoid treating the partner array order or legacy score as the policy itself.
10
+
11
+
## Order Strategies
12
+
13
+
### `static-curated`
14
+
15
+
Use for surfaces where the order is editorially or commercially curated and should remain stable. These surfaces can preserve the existing order, use partner seniority, or use private commercial priority when seniority is unavailable.
16
+
17
+
Do not expose private commercial criteria in client-facing field names, comments, or API responses. If a private priority is required, keep the public/client value generic, such as `placementPriority` or an already-resolved ordered list.
18
+
19
+
### `tier-rotated`
20
+
21
+
Use for visible partner surfaces where partners in the same tier should cycle over time. Tier order remains fixed, but partners inside the same tier are selected with weighted-random ordering for each page view and surface.
22
+
23
+
The root loader creates the initial page-view seed, so SSR and hydration receive the same value through loader data. A React provider owns the seed after hydration and refreshes it on client-side page views. Each surface combines its stable surface id with the page-view seed; avoid runtime-generated component ids in the seed because they can diverge across server and client rendering. Partners default to equal probability within their tier; a future `placementWeight` can bias same-tier odds without changing the ordering API.
24
+
25
+
### `contextual-recommendation`
26
+
27
+
Use when a surface behaves like a product recommendation or builder suggestion. Product fit should be established before commercial weighting affects order. This strategy currently preserves the legacy tier/priority behavior while giving recommendation surfaces a separate policy label.
28
+
29
+
### `machine-readable`
30
+
31
+
Use for AI- or crawler-facing outputs such as `llms.txt` and JSON feeds. These should be deterministic and relevance-first. Do not rotate them merely for logo fairness unless the downstream behavior has been designed and disclosed as such.
32
+
33
+
## Reserved Rules
34
+
35
+
Reserved rules should be narrow. For example, Cloudflare is reserved as the first deployment/hosting partner in any list that contains Cloudflare and other deployment partners. That should not imply Cloudflare is globally first across every partner surface; non-deployment partners can still appear before Cloudflare when the surface is mixed-category.
36
+
37
+
Deployment action buttons are a deployment-only surface. Cloudflare remains first when present. Tier order is still preserved, and providers within the same tier can rotate by page view.
38
+
39
+
## Current Surfaces
40
+
41
+
- Partner directory: `tier-rotated` for active partners, `static-curated` for previous partners.
42
+
- Partner grids and embeds: `tier-rotated`.
43
+
- Docs and blog rails: `tier-rotated`.
44
+
- Mobile docs strip: `tier-rotated`.
45
+
- Builder feature picker and starter partner suggestions: `contextual-recommendation`.
46
+
- Deploy action buttons: `tier-rotated` with deployment provider tiers preserved.
47
+
-`llms.txt` and `/api/data/partners`: `machine-readable`.
48
+
49
+
## Analytics
50
+
51
+
Partner impression and click events should include:
52
+
53
+
-`partner_id`
54
+
-`placement`
55
+
-`slot_index`
56
+
-`partner_tier`
57
+
-`order_strategy`
58
+
-`rotation_seed` when the strategy rotates
59
+
60
+
This lets reporting distinguish partner performance from placement policy and makes under/over-exposure easier to debug.
61
+
62
+
## Contract Language
63
+
64
+
Suggested external framing:
65
+
66
+
> Partner tiers determine eligibility, visual treatment, reporting, and relative access to surfaces. Placement within the same tier may rotate or be curated depending on the surface. Some placements may include explicitly reserved rules for product, infrastructure, legal, or strategic reasons.
67
+
68
+
For AI-assisted selection:
69
+
70
+
> AI-assisted partner selection prioritizes user need and capability fit first. Partner tier may influence selection only among qualified options.
0 commit comments