Setting the referer policy
  • 25 May 2021
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Setting the referer policy

  • Dark
    Light
  • PDF

The referer policy on the web player iframe code determines which referer data we get for these plays and what we can display in the "Sources" tab of our analytics dashboard.

See this article for full technical details on best practices for Referer Policy. We provide a quick overview and how it impacts publishers using our player.

What is the referpolicy setting ?

When our web player is embedded as an HTML iframe code on a website, setting the "Referer Policy" allows us to show better referer data in the analytics dashboard.

Instead of always showing it's own URL (iframe.iono.fm) our player will attempt to get the name and path of the webpage that it is embedded in, for example example.com/myshowname. This allows publishers to better understand what pages are driving their traffic.

The referer policy determines how much of this data the web player will be able to get.

How to change the policy ?

When embedding our web player, the basic generated iframe code looks something like this:

<iframe src="https://iframe.iono.fm/c/123" 
        width="100%" 
        height="450" 
        refererpolicy="origin">
</iframe>

Our iframe generator has a drop-down setting that allows choosing one of 3 possible values for the refererpolicy:

Setting name Referer policy Description
No website data no-referrer All listens in the web player will show iframe.iono.fm on the referer page.
Website name only origin Default policy. Web player listens shows the external site name example.com but without the specific page URLs.
Full page URLs unsafe-url Shows the external site name example.com and the page URLs, ex: /myshowname.

Which one should I use ?

Our default is "Website name only" which sets the origin policy. This allows us to get the website name but not the path or URL parameters. This is a safe balance between getting valuable information but with a low chance of leaking personal or sensitive information.

We recommend using "Full page URLs" (unsafe-url) for most of our publishers if it's important to understand which of their pages pages are driving listener traffic and they are not using any personal or sensitive data in their URLs.

Examples of personal or sensitive data may be a username, authentication token or something similar that is unique to the user. These are typically used in the URL query parameters, ex: example.com/myshowname?username=testuser. When you do set this type of information in your URLs, it is important to understand how we use your data before setting unsafe-url.

How do we process the full (unsafe) referer URL ?

We store and display only the "domain" and "path" parts of the full URL in our analytics. We strip out any URL query parameters and do not store or display these in our analytics dataset. This allows even publishers with personal data in their URL query parameters to use our "Full page URLs" with low risk.


Was this article helpful?