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

    Setting the referer policy

    • Updated on 25 May 2021
    • 2 Minutes to read
    • Dark
      Light
    • PDF
    Article summary

    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 nameReferer policyDescription
    No website datano-referrerAll listens in the web player will show iframe.iono.fm on the referer page.
    Website name onlyoriginDefault policy. Web player listens shows the external site name example.com but without the specific page URLs.
    Full page URLsunsafe-urlShows 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.

    What's Next