The email to send an SDK vendor before you integrate

Most SDK evaluations happen backwards. Someone reads a landing page, integrates in an afternoon, ships it, and finds out what they agreed to when a user asks a question they cannot answer.

The cheaper order is to send an email first. Below is the one we would send — including to ourselves — with what a good answer looks like, because a list of questions without that is just a list.

Copy it. Send it to two vendors. The one that answers better is usually the one to integrate, and a vendor who will not answer in writing has answered.

---

The email

Hello — evaluating your SDK for our app. Before integrating, could you answer the following in writing?

1. Which limits can we change as the integrator, and which are compiled into the binary?
2. Are any limits read from server-side configuration that you can change without us shipping a build?
3. What happens when the device is under sustained load — throttle, or opt out entirely?
4. Does the SDK run continuously within limits, or only when the device is idle? If the latter, how is "idle" determined?
5. Can we see the exact consent screen our users will be shown, before integrating?
6. Can the SDK transmit anything before consent is granted? What enforces that?
7. What are the categories of traffic relayed, and who are the buyers?
8. What destinations are permanently blocked, and is that enforced on the server as well as the client?
9. What is the per-ABI binary size, and can we split by ABI?
10. What does the SDK do on network transitions, process death, and doze?
11. What happens on a cold boot on a low-end device, and what physical hardware do you test on?
12. How exactly is a paid user defined — minimum daily activity, partial-month handling, and which devices are excluded?
13. Can we run a live device today without a sales call or contract?
14. What is your process when a destination is reported for abuse?

---

What the answers should look like

1–2. Limits and configuration

Good: "None. They are compiled into the core and there is no API to change them. The relay enforces the same limits independently."

Disqualifying: any answer where you can raise a cap. If you can, the cap is a suggestion and whatever the SDK does on your user's phone is now your liability. Question 2 is the sharper one — a limit read from server config can be changed without you shipping anything, which means it is not a limit you control either.

3–4. Behaviour under load

Good: "Opts out entirely and checks back later."

Weak: "Throttles." Throttling keeps the SDK resident and competing for resources on a device already struggling — the difference between a support ticket that says "the app got slow" and one that never exists.

On question 4, be suspicious of "only runs when idle." Deciding what idle means on a phone is genuinely hard — screen off is not idle, charging is not idle, a background sync is not idle — and most implementations solve it by not really solving it. A vendor claiming "idle-only" operation either has something sophisticated they can describe in detail, or is describing something they do not do.

5–6. Consent

Good: they send you the screen, or a link to it, immediately.

Disqualifying: "You will see it after integration." The consent screen is what your users read and what a store reviewer judges. Not being allowed to see it before writing code tells you what you need to know.

Question 6 is the architectural one. The right answer is that transmission before consent is impossible, not discouraged — not a settings toggle defaulted on, not a clause in a licence agreement.

7–8. Traffic and blocking

Good: a specific list of categories and a specific blocklist, including the user's own local network.

Disqualifying: vagueness. "Public web data" alone is not an answer. If a vendor cannot tell you what is blocked, nothing is. Where shared bandwidth actually goes is our long-form answer to both, including the parts that are uncomfortable.

The server-side half of question 8 matters because a blocklist living only in the client is a suggestion — the client runs on someone else's device and can be tampered with.

9–11. What it costs you

Ask for per-architecture binary size, not the total, and whether you can split by ABI in your bundle. You usually can, and most vendors will not mention it.

Question 11 is the one that separates vendors who have shipped from vendors who have demoed. Android kills a process that does not foreground a service fast enough, and the failure appears only on slow hardware at cold boot — never on an emulator. A vendor who has hit this will answer in specific detail because it is memorable.

12. How you actually get paid

This is where money quietly differs and it is almost never on the pricing page. Two vendors quoting the same headline rate can pay materially different amounts for the same install base.

Ours, for comparison: a user counts for a day once their device has been sharing for 60 minutes in that UTC day; each qualifying day is worth the monthly rate divided by the days in the month; a device sharing 59 minutes earns nothing for that day. Devices on hosting, datacenter or VPN IPs are not counted.

Disqualifying: an evasive answer. A vendor who will not define a paid user in writing is reserving the right to redefine it.

13. Whether you can test at all

Good: yes, today, with a key you generate yourself.

Weak: a call, a contract, a minimum commitment. Not because sales calls are sinister, but because they prevent the only test that matters — integrate behind a flag, ship to 1% of users, watch crash-free rate and retention for a week.

14. Abuse

Ask what happens when someone reports a destination. A vendor with no answer has no process, and the blocklist is therefore a static file rather than a commitment.

Then do the test anyway

The email is a filter, not a verdict. Whatever comes back:

1. Integrate behind a feature flag.
2. Ship to about 1% of users.
3. Watch crash-free rate, ANRs and retention for a full week.
4. Widen only if all three are flat.

That week costs an afternoon and catches almost everything the email cannot. How to evaluate a passive income SDK has the longer version of the reasoning, and how it works is where our own answers live.