For a large group of products the thing being sold is a number. A monthly repayment, a yearly saving, an insurance premium, a bill after switching, a plan's price for this particular household. A static ad can only quote a typical figure, which is either too good to be believed or too generic to care about. A calculator ad lets the viewer produce their own: more persuasive, because it is theirs, and more honest, because it is not a cherry-picked example.
Catalogue ads share the same underlying shape. Six broadband plans, eight properties, twelve products: one card design and a table of rows. Both are data-driven playables, and both are much easier to build once you stop thinking of them as screens.
Think in state, rules and views
Every calculator ad reduces to three parts. State: variables holding what the viewer chose (the amount, the term, the plan). Rules: actions and formulas that change that state when the viewer does something. Views: text, bars and cards that display the state wherever it is needed.
Built as screens (one layout for each combination of inputs), a modest calculator becomes hundreds of objects and thousands of visibility toggles. Built as state, it is a handful of variables, one formula and a few lines of copy with the numbers dropped in. The second version is also the one that can be changed later, when the rate moves, without an afternoon of hunting through objects.
Inputs: let the viewer set the number
- A slider for amounts: how much to borrow, how much to save each month. Bound it to the real product's minimum and maximum, never a wider range that produces figures nobody can actually get.
- A stepper for small whole numbers: the term in years, people in the household, cars on the policy.
- A toggle for yes-or-no factors: existing customer, add a second line, include breakdown cover.
- Defaults set to the most common case, not the most flattering one. The default is what most viewers see, so it is the number the ad is really quoting.
Formulas: the maths has to be the real maths
Simple arithmetic covers a surprising amount (a monthly cost is price times quantity divided by twelve) but the products that most need a calculator often need real formulas. A loan repayment is the standard amortisation formula: payment = P × r ÷ (1 − (1 + r)^−n), where P is the amount, r the monthly rate and n the number of payments. It needs powers, rounding to two places and clamping at the ends of the range, and none of those can be approximated without producing a wrong figure somewhere in the range.
A calculator makes claims
Every result is a quote the viewer can screenshot. Use the rate the landing page will actually offer, label estimates as estimates, and show the assumptions beside the result. In many jurisdictions a repayment figure in an ad triggers mandatory disclosures, such as a representative example or APR, which makes the result screen regulated copy. Have it reviewed by whoever reviews the rest of your financial advertising.
Lookup tables for tiers
Real pricing is rarely one formula. Rates change by band, premiums by age bracket, plans by household size. Nested conditions (if the amount is over this and under that) are hard to read and easy to get wrong exactly at the boundaries. A lookup table expresses the same thing as data: a list of thresholds and the value each maps to, checked in one step. When the bands change, you edit the table, not the logic. For a single yes-or-no decision an inline condition is simpler; for three tiers or more, use the table.
Formatting: 12,480.50 is not 12480.5
An unformatted number looks like a bug. Money needs digit grouping and exactly two decimal places; a percentage needs its sign; large round numbers read better compact, as 12.5k. The currency symbol belongs in the copy rather than the number (£{monthly|money} a month) because the formatter cannot know which currency you mean.
Then check the longest number your inputs can produce, in both orientations. 12,480.50 is a much wider string than 980, and a result that wraps onto two lines at the maximum input is a layout bug that appears only at the edge of the range, which is exactly where nobody looks during review.
Catalogue playables: one card, many rows
For catalogue-shaped products the key object is a repeater: design one card, bind it to a table of rows (plan name, price, data allowance, image) and it produces a card per row. Changing a price means editing a row rather than finding one text object among fifty, and a new plan is one more row. It helps the byte budget as well: one card design plus a table of text is far lighter than six hand-built compositions. Pair it with filter chips where viewers need to narrow the range, and write the selected card's values to variables so the summary screen and the click can use them.
End on their number, and pass it on
The last screen should restate the inputs and the output together (£15,000 over 5 years: £297.50 a month) with a call to action about that figure: get this quote, check my rate. Then carry it through the click. With a web destination the inputs can travel as query parameters, so the application form opens pre-filled instead of asking the viewer to type everything again: the most avoidable drop-off in the entire funnel.
Test the edges, not the middle
- Set every input to its minimum and its maximum, and try zero wherever zero is possible. Division by zero and empty ranges surface here as NaN, Infinity or a blank.
- Hand-check three combinations against the calculator on your own website. If they disagree, one of them is wrong, and it matters which.
- Check the largest result in both orientations and in every language you ship.
- Confirm the number carried into the click-through is the one on screen, not a stale default.
Building one in Playable Ads Maker
Declare Number, Text and Boolean variables once in the Variables manager. Slider, Toggle and Stepper objects write to them directly; Set Variable actions change them on any trigger, with an optional condition; formulas and lookup tables do the maths; and a {token} with a format such as money or pct puts the result into any line of copy. Repeater and Chips handle catalogue layouts, and a Show If Variable gate reveals the right card or result. The formula evaluator is hand-written rather than built on eval, so it keeps working in the strict webviews where eval is blocked. The Price Simulator interactive module packages the same idea ready-made (sliders and plans re-pricing live) in Insurance – Price Your Cover.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker