ChirplyHow do you test dynamic number insertion?
Test the visible phone number and the clickable phone link under controlled source and browser conditions. Then place an authorized test call and compare the landing source, assigned number and resulting call record. Include repeat visits, direct visits, consent behavior, mobile links and a fallback case.
A team is preparing a call-tracking website. This worksheet tests whether the configured system preserves the intended source and a usable phone destination. Expected values depend on the selected provider and configuration; the synthetic cases specify what to verify rather than pretending a test has already passed.
Dataset and download
Download example CSVOpen the CSV in a spreadsheet and keep the original as a reference. Make a working copy for your own review. Downloading saves a local file; it leaves your CRM and communication settings unchanged.
| case_id | scenario | check | evidence_to_record | status | data_type |
|---|---|---|---|---|---|
| DNI-1 | fresh tagged visit | visible number and tel link match assigned number | source; assigned number; screenshot; test call ID | to test | synthetic |
| DNI-2 | repeat visit | assignment follows configured session rules | session rule; before and after number | to test | synthetic |
| DNI-3 | direct visit | configured direct or fallback behavior | entry URL; attribution rule; result | to test | synthetic |
| DNI-4 | mobile tap | tap opens intended complete phone destination | device; visible number; tel destination | to test | synthetic |
| DNI-5 | consent choice | behavior follows implemented consent settings | consent state; displayed number; recorded fields | to test | synthetic |
| DNI-6 | script unavailable | usable fallback number remains visible | fallback number; call route | to test | synthetic |
Field definitions
- scenario
- A distinct visitor or delivery state. Use your own authorized test browser and phone.
- check
- The observable assertion; replace provider-dependent expectations with your actual configuration.
- evidence_to_record
- An evidence checklist, not customer data. Keep phone numbers and private call records in your own controlled test log.
- status
- Start at to test; record pass, fail or blocked only after an observed result.
Reproduce the method
1. Document the configured rule
Record the source matching, session duration, number pool, fallback number and forwarding destination. Read the current provider settings. A fixed source number and a visitor-level pool answer different questions, so name which configuration you are testing.
2. Run one source at a time
Open a fresh browser session with a controlled campaign URL. Inspect the visible number and its tel link. Record the expected source and observed assignment. Use the UTM builder for consistent labels, and repeat with a direct visit under the documented rule.
3. Verify the call end to end
With permission to place a test call, call the displayed number from your own phone. Confirm the destination and inspect the resulting call record. Match it using the provider's call identifier and timestamp. Record any provider usage charges under the ordinary test budget.
4. Exercise mobile and fallback states
Run the mobile, consent and unavailable-script cases. Confirm a usable phone destination remains accessible under the intended behavior. Record failures with the page URL, state and evidence. Repeat a failed case after correction before marking the deployment ready.
Expected results
- Six distinct cases are present in the worksheet; all start at to test.
- For a passing replacement case, the visible number and tel destination agree with the configured assignment.
- A passing end-to-end case has an observed test call record and the expected routing/source fields; a screenshot alone proves only display behavior.
Interpret the result
A successful display replacement does not establish attribution accuracy. Keep the call identifier and source evidence together.
Use the provider's documented pool-sizing and session behavior. This worksheet provides a QA method rather than an invented universal pool-size formula.
If the browser or consent state limits observation, record that limitation. Missing attribution is an unknown value, not proof of a direct visit.
Troubleshooting
Text changes but tapping calls the original number
Inspect every phone link, including sticky headers and mobile menus. The replacement integration must cover the displayed text and actual tel destination.
The call arrives with an unexpected source
Compare session rules, redirects, UTM preservation, assignment timing and provider record timestamps. Reproduce one controlled journey before testing several campaigns together.
If the CSV does not appear immediately, check your browser's downloads list. Import it as UTF-8 with comma-separated fields if your spreadsheet opens it in one column.
Questions about this example
Can this worksheet configure number insertion?
The CSV is a QA record. Configure your tracking integration and numbers separately, then use the cases to verify the result.
Should every visitor see a different number?
That depends on whether you use source-level tracking or a visitor/session pool. Define the intended assignment model and test against its configured rules.
Sources and next steps
- Call-tracking setup guide
- Dynamic number insertion definition
- Build a tagged campaign URL
- Explore call attribution
The methodology and synthetic rows were authored for this resource and checked against the linked definitions and product guides. Product setup and provider conventions remain documented at their sources. Cite this page's address and review date when sharing the exercise; keep the synthetic-data label with copied rows.