Measurement
Podcast campaign landing pages
Plan a podcast landing page that matches the spoken offer, works on mobile and measures visits and outcomes with appropriate limits.
A podcast campaign landing page should confirm the offer a listener heard and make the promised next step easy to take. Give listeners a destination they can remember, explain the offer and its conditions, and make the action work on a phone. Measure visits and outcomes separately; neither proves that someone heard the ad.
Start with the promised action
Write down what the ad asks listeners to do before designing the page. Claiming an offer calls for a different journey from comparing a considered purchase. The headline should confirm that the visitor has reached the right place. The next useful detail should explain what is available and who qualifies.
| What the ad promises | What the page should clarify |
|---|---|
| An offer | The benefit, eligibility, any end date and how to claim it |
| More information | The question the page answers and where to explore further |
| A consultation or enquiry | What happens after submission and what details are required |
Keep important conditions near the claims they qualify. If the ad specifies new customers, say so before checkout. Check that the page and any recordings still in circulation agree when an offer changes or ends.
Match the page to the spoken promise
- An offer
- Clarify the benefit, eligibility, any end date and how to claim it.
- More information
- Clarify the question the page answers and where to explore further.
- A consultation or enquiry
- Clarify what happens after submission and what details are required.
Give listeners a practical route
A short path on the advertiser's own domain can be easier to say than a long campaign address. Read it aloud and check whether an unfamiliar listener can spell it. Send that path to the relevant offer or information page, rather than making visitors search from the home page.
If the path redirects, check the destination on a phone and decide what the route will show after the offer expires. A companion link may carry campaign tags. Those tags identify use of that link when they reach the analytics setup; they do not identify someone who typed the spoken address.
Set up a spoken campaign route
- Choose a short path on your own domainA short path can be easier to say than a long campaign address.
- Read it aloud and check spellingCheck whether an unfamiliar listener can spell the path after hearing it once.
- Send the path to the relevant pagePoint to the offer or information page rather than making visitors search from the home page.
- Check redirects on a phoneFollow the route on a mobile device and confirm the destination works.
- Decide what the route shows after expiryPlan the post-offer state so the page does not mislead later visitors.
- Use companion links with campaign tagsTags identify use of that link in analytics; they do not identify someone who typed the spoken address.
Make the next step work on mobile
Put the promise, its key condition and the main action where a mobile visitor can find them. Name the action on the button, such as “See available plans” or “Start an enquiry”. If a code is needed, show where to enter it and when the benefit appears.
Ask for the information needed for the next step. Give form fields clear labels and explain errors. Check the page with the keyboard open and text enlarged so banners or fixed buttons do not hide the action or a field.
Mobile action check
- Put the promise, key condition and main action where a mobile visitor can find them
- Name the action on the buttonFor example: “See available plans” or “Start an enquiry”.
- If a code is needed, show where to enter it and when the benefit appears
- Ask only for the information needed for the next step
- Give form fields clear labels and explain errors
- Check with the keyboard open and text enlargedEnsure banners or fixed buttons do not hide the action or a field.
Make controls clear to every visitor
A form label should describe its control and be associated with it in the page code. The W3C recommends an explicit association where possible: the label’s “for” value must exactly match the control’s “id”. This also makes the label a larger clickable area and helps assistive technology identify the control.
A label can be visually hidden when its purpose is already clear from nearby content, but it should remain available in the code. The W3C notes that “aria-label” and “aria-labelledby” are supported by assistive technology, but their text is not conveyed to visual users; use them only when the surrounding content makes the control’s purpose clear.
Form labelling options
- Explicit label associationUse where possible; the label’s “for” value must exactly match the control’s “id”. This also makes the label a larger clickable area and helps assistive technology identify the control.
- Visually hidden labelCan be used when the purpose is already clear from nearby content, but the label should remain available in the code.
- aria-label or aria-labelledbySupported by assistive technology, but their text is not conveyed to visual users; use only when surrounding content makes the control’s purpose clear.
Report response signals separately
Report visits to the campaign path, completed enquiries or purchases, and code redemptions as different measures. The same person can appear in more than one. A dedicated path can also be reached through a shared link.
For purchases, compare code use recorded by the order system with any analytics report. A code user may not have heard the podcast, while an influenced customer may never use the code. Describe what each system recorded rather than presenting either measure as total podcast response.
Separate response signals
- Visits to the campaign pathShows traffic to the path, but the same path can also be reached through a shared link; it does not prove that someone heard the ad.
- Completed enquiries or purchasesShows outcomes recorded by the site or order system; the same person can appear in more than one measure.
- Code redemptionsShows code use recorded by the order system; compare with any analytics report because a code user may not have heard the podcast, while an influenced customer may never use the code.
Check the journey before launch
Ask someone unfamiliar with the campaign to hear the address once and try it. On a phone, follow the route, read the offer, complete the main action and check the confirmation. Try relevant ineligible or expired states.
Performance tools can help identify problems, but the action itself still needs checking. Assign an owner to the route, offer terms, tracking and expiry state.
Pre-launch journey check
- Ask someone unfamiliar with the campaign to hear the address once and try it
- On a phone, follow the route
- Read the offer
- Complete the main action
- Check the confirmation
- Try relevant ineligible or expired states
- Assign an owner to the route, offer terms, tracking and expiry state
Assess page performance with care
Core Web Vitals assess loading performance, response to user input and layout stability. A performance result is not a measure of whether the offer or action is clear.
Lighthouse runs laboratory tests in simulated conditions, which can help diagnose potential performance problems. Its results may not reflect the range of devices, networks and experiences visitors encounter in real use, so treat the tool as a diagnostic rather than a complete picture of visitor experience.
The Chrome User Experience Report uses data from some real Chrome users, but it may not include a site with too little traffic. Its data is a moving average of the previous 28 days, so it is not suited to checking a change during development. Where available, compare field data with diagnostic results and allow for those limitations when reviewing a campaign page.
Performance data comparison
- Core Web VitalsAssess loading performance, response to user input and layout stability. A performance result is not a measure of whether the offer or action is clear.
- LighthouseRuns laboratory tests in simulated conditions, which can help diagnose potential performance problems. Results may not reflect the range of devices, networks and experiences visitors encounter in real use; treat as a diagnostic rather than a complete picture of visitor experience.
- Chrome User Experience ReportUses data from some real Chrome users, but may not include a site with too little traffic. Data is a moving average of the previous 28 days, so it is not suited to checking a change during development. Where available, compare field data with diagnostic results and allow for those limitations when reviewing a campaign page.
In this guide
- Choosing a memorable podcast destination URLChoose a spoken podcast URL listeners can recall, verify its redirect and plan how the route will work after the offer ends.
- Matching the landing page to an audio offerCheck that a podcast landing page repeats the spoken offer accurately, explains conditions and gives visitors the promised next step.
- Tracking typed visits and code redemptions separatelySeparate visits to a spoken podcast URL from accepted code orders, and learn why neither measure proves who heard the ad.
- Testing a mobile landing page before an audio campaignTest the spoken route, mobile offer journey, form, code, performance and tracking before a podcast campaign starts.
