Free resource · use it on this page
Platform Selection Scorecard
A weighted scorecard you fill in on this page to turn a push-platform shortlist into a defensible fit score per platform.
How this scorecard works
This is a weighted-criteria scorecard: 16 criteria across two tables, each with a weight from 1 (nice to have) to 5 (critical) and a score from 1 to 5 per platform. Multiply weight by score for each row, sum the column, and you get one comparable fit number per platform. Print this page or copy the tables into a spreadsheet and fill them in directly.
Weighting is what makes the number defensible. An unweighted feature checklist treats a missing webhook the same as a missing iOS SDK, which is how teams end up choosing the platform with the longest feature list rather than the one that fits. The suggested weights below are sensible defaults for a mobile app team; adjust them to your context in Step 1, and lock them before you sit through any vendor demo so a good sales narrative cannot quietly reorder your priorities.
Budget 60 to 90 minutes with a shortlist of two or three platforms. The scorecard will not make the decision for you, but it will surface exactly where your evaluators disagree, and that disagreement is usually the real decision.
Step 1: Frame the decision
Fill these in before touching the scoring tables. Every later step refers back to this frame.
Primary use case
The one job push must do well: transactional alerts, re-engagement, promotions, or breaking updates. Write one sentence; if you need two, you have two use cases and should weight for the more valuable one.
Audience size, today and in 12 months
MAU or subscriber count. Pricing models diverge sharply with scale, so score the pricing row against the 12-month number, not today's.
Shortlist: Platform A / B / C
Name at most three platforms. More than three turns scoring into a survey and the weights stop being honest.
Hard requirements
True dealbreakers only: EU data residency, a required compliance regime, a mandatory on-prem option, a specific SDK platform. Mark the matching rows below with a star; they become veto rows in Step 5.
Monthly budget ceiling
Include engineering time for integration and maintenance, not just the license. A cheap platform with a heavy SDK is not cheap.
Scoring team
At least one engineer and one marketer or PM, scoring independently before comparing. Averaged solo scores hide disagreement; independent scores expose it.
Decision date
A scorecard without a deadline becomes documentation. Set the date you will commit, and the earlier date by which trials must be running.
Step 2: Score reach and delivery
Score each platform 1 to 5 per row. Use these anchors: 5 = verified in your own trial, 4 = demonstrated live in a demo on your scenario, 3 = documented but unverified, 2 = possible only via workaround, 1 = absent. Adjust the suggested weight first if your frame in Step 1 demands it.
| Criterion | What a strong platform shows | Weight 1-5 (suggested) | Platform A score | Platform B score | Platform C score |
|---|---|---|---|---|---|
| OS and surface coverage | First-class iOS and Android SDKs at parity, plus web push if you have a web audience. Gaps here cannot be patched later. | 5 | |||
| Opt-in and permission tooling | Built-in soft-prompt or permission-priming flows, and visibility into opt-in rate by platform. The best delivery pipeline is worthless below a healthy opt-in rate. | 4 | |||
| Delivery feedback | Per-message delivery and failure reporting, not fire-and-forget sends. You should be able to answer 'did user X receive campaign Y' from the dashboard or API. | 4 | |||
| Throughput and send speed | Documented send throughput and predictable fan-out time for your full audience. Matters most for time-sensitive sends like flash offers or live updates. | 3 | |||
| Frequency controls | Global frequency caps, quiet hours by recipient time zone, and per-user throttles that apply across campaigns, not per campaign. | 3 | |||
| Token and subscriber hygiene | Automatic pruning of invalid tokens, uninstall detection, and honest audience counts. Platforms that never shrink your audience are hiding decay, and often billing you for it. | 3 | |||
| Beyond-app reach | Channels that reach users without an installed app: web push, and Apple or Google Wallet passes on the lock screen. Generalist push tools rarely cover wallet; wallet-native platforms such as PushNotice specialize in it. Score 5 only if the channel you need is first-class, 3 if it works through a partner integration. | 3 |
Step 3: Score build and operations
Same 1-to-5 anchors as Step 2. These rows decide what the platform costs you after launch, which is where most regret lives.
| Criterion | What a strong platform shows | Weight 1-5 (suggested) | Platform A score | Platform B score | Platform C score |
|---|---|---|---|---|---|
| SDK quality and footprint | Small binary size impact, active release cadence, changelog honesty about breaking changes, and no history of crash-causing releases you can find in their issue tracker. | 4 | |||
| Documentation and time-to-first-send | One engineer can integrate the SDK and deliver a test push to a real device in under a day using only public docs. Time this during your trial; it predicts every future integration task. | 4 | |||
| Segmentation and targeting | Audiences built from events and user properties, updated in near real time. Batch-only audiences that refresh daily quietly break triggered use cases. | 4 | |||
| Automation and journeys | Event-triggered sends with delays, branching, and exit conditions. Score against the journeys you named in Step 1, not against the vendor's gallery. | 3 | |||
| Analytics and attribution | Opens, downstream conversion tracking, uninstall correlation, and raw export to your own warehouse. If you cannot export it, you do not own it. | 4 | |||
| API and webhooks | A full send-and-manage API with documented rate limits, plus outbound webhooks for delivery and engagement events so your own systems can react. | 3 | |||
| Data handling and compliance | Data residency options you need, retention controls, a signable DPA, and tooling for deletion requests. Star this row as a veto if Step 1 listed a compliance requirement. | 4 | |||
| Pricing model fit | A model (per-MAU, per-send, or flat) that stays sane at your 12-month audience number from Step 1. Model the bill at 2x and 3x scale before scoring; cliffs count against the score. | 4 | |||
| Migration and exit path | Documented export of tokens, subscribers, and segment definitions. An easy exit is negotiating leverage forever; a locked-in audience is not yours. | 3 |
Step 4: Compute the fit score
- 1
Lock the weights
Finalize every weight before the first demo or trial. Record the date. Weights changed after a demo need a written reason, or the scorecard becomes a justification machine for a decision already made.
- 2
Score independently, then reconcile
Each scorer fills their own copy using the 1-to-5 anchors. Where two scorers differ by 2 or more points on a row, discuss that row only, then agree a final score. These arguments are the most valuable output of the exercise.
- 3
Multiply and sum
For each row, multiply weight by score. Sum each platform's column across both tables to get a raw total per platform.
- 4
Normalize to 100
Divide each raw total by the maximum possible (the sum of all your weights times 5), then multiply by 100. This gives a fit percentage that stays comparable even after you change weights or drop criteria.
- 5
Run the veto pass
Check every starred hard-requirement row from Step 1. Any platform scoring 1 or 2 on a starred row is eliminated regardless of its total. A high average never compensates for a failed dealbreaker.
- 6
Verify the top two in a trial
Re-score every row you originally scored a 3 (documented but unverified) after hands-on trial use. Docs-based scores drift down far more often than up, and the ranking can flip.
Step 5: Read the result
As working bands for this scorecard: a normalized score of 85 or above is a strong fit; 70 to 84 is workable, provided you list the low-scoring rows as known gaps with an owner and a mitigation; below 70 means your shortlist does not match your requirements, so either revisit the weights or widen the shortlist rather than forcing a winner.
Treat platforms within about 5 normalized points of each other as a tie. Break ties on the migration-and-exit row and on switching cost, not by re-scoring until a favorite wins. If a platform leads only through many low-weight rows while trailing on your 5-weight criteria, the weights are telling you it is the wrong winner; trust them or change them openly.
Date the completed scorecard and keep it with the contract. Re-run it before every renewal and whenever the audience crosses the 12-month number you wrote in Step 1. The second pass takes twenty minutes and is the cheapest vendor review you will ever do.
From the guide: Best Push Notification Tools (2026)
This resource accompanies the full article — worth reading before you commit to a tool.