Studio's new dynamic player


We have re-launched the dynamic player to bring a fresh new look along with a host of new features and functionality to further enhance user experience and workflow.

Feedback from both power and new users has helped us to build upon one of the core components of our application, making the task of reviewing and playing back any possible version of your dynamic audio advert a very easy one.


The minimised media player can be launched from anywhere in Studio where you see the triangle play button, and when playing a script (as opposed to an individual media file), the minimised media player includes the option to expand the player to reveal the dynamic player. The expand button is a chevron in form, and is positioned to the right of the play button.

Script playback, with access to the dynamic player is achieved via the play button found in the red FAB menu in the bottom right corner of the script edit page, or from the play button positioned beside the script name in the campaigns page of your dashboard.

Media playing

In addition to the functionality already available- such as play/pause, and download the mp3 of the playing version of your ad, we’ve included more information in the new minimised dynamic player. The names of your script, campaign and client are now displayed alongside the media player controls and these all link to the corresponding pages in your dashboard.


A brand new feature is the script read through, which is displayed on the left side of the expanded dynamic player.

This component highlights each line of the script as the playing media reaches it, and offers an easy way of skipping to other points in the advert- by clicking a line the playhead moves to the corresponding point in the script.

Each line is accompanied by icons to denote the rule types (weather, location etc) that affect the option that is being played.

Conditions Selector

Selecting a script version in the new dynamic player introduces the ability for you to choose between hearing a dynamically produced ad, the one that contains the default options, or one using all of the shortest or longest media files.

Selecting conditions was the core of the previous incarnation of the dynamic player, and this has largely remained unaltered, save for the addition of options for both ‘no-value’ and ‘auto’ where possible.

Selecting a different script version, or different conditions automatically loads the appropriate version of your advert in the media player- so all that is left for you to do is hit play and hear as your audience will.

On top of all of these great new features, the redesign creates a more intuitive workflow, whilst maintaining a consistent and familiar look and feel for regular users.

Creating demo users and sharing multiple scripts at once

The simplest way to send the demo player for a script of the analytics page is to use the sharing link (detailed in this blog post). However, sometimes you want to send more than one script and stop it expiring after 30 days (as the share links do). For this, its best to create a demo user and then share scripts with that user.


Create a user with User Type of Demo. This prompts you to give the user a name and choose a pass code. To share scripts with this demo user, go to each script’s settings panel and choose this user to share the script with on the sharing tab.
The image below shows the “Become a monster” script is shared with the “7stars” demo user.

Then from the user menu, you can get the short link to share:

Click the link symbol to copy a short link to your clipboard e.g.

You can share this link with your contacts along with the passcode and when they click it, a log in box will appear, prompting for the passcode.

When the user logs in they see the demo player with all of the scripts that have been shared with that user. This way you can send many scripts in one demo player.

Managing users, groups and roles

This post outlines how we handle users, groups and roles in the Studio.

You can create a new user by clicking the + button at the bottom of your user group.


Creating a new user will send them an email to verify and let them choose a password.

User groups


Every user is a member of a user group. Users within the same group can see the same set of clients, campaigns and scripts. What they can do to those elements in governed by their individual role. 


Every user is assigned a role that governs what they are able to do in the Studio. The table below shows which roles can do what:

Role Create user groups Create, delete, edit users in your group Create, delete, edit clients and campaigns Create and delete scripts Publish scripts Edit scripts View scripts
User Group Administrator
Script Administrator
Script Publisher
Script Editor

There is a special type of user called a Demo user that can be shared with others in order to share multiple scripts in one demo player. See this post for details on how to create a demo user.

Integrating with A Million Ads

Integrating with A Million Ads is simple as we follow standard HTTP, REST, VAST and DAAST standards. VAST, in particular, is wide spread amongst most ad tech providers and governs the kind of request that we take and the format of the response.


The tag

We provide the tag within our Studio ad designer tool when a script is ready to be published.

Here is a sample tag that can be inserted in to the creative flight on an ad server / SSP / DSP (usually in the VAST redirect box):

GET${segment}&data.age=${ageband} Link

This tag can be a HTTPS GET or POST.

The unique code (wR3Ckk) is the reference to the script - in this case, it is a simple 15 second test message.

The source is set to ama - this lets our system know who is requesting the ad, what format the data is being passed to us in and in what format we will return the response. This is all set up in a pre-defined config file called a parser.

Data can be passed to trigger different elements in the script. This can be done as key=value in the query string, JSON formatted in the data field in the query string, or as XML or JSON in the POST body. In this example, the key value pairs data.segment and data.ageband are in the query string and the values are example macro codes that might trigger the DSP to populate some date into the tag on each request.

The response output can be VAST (IAB standard XML), JSON, or even a 303 redirect to the file itself.  This tag responds with a VAST document containing the URL of the media asset (audio file encoded as required e.g. OGG), any impression, start and complete tags, third party trackers, and any associated companion image and companion click (not all are in this particular response).

Companion images and clicks are supported and they can change dynamically in tandem with the audio - that is all set up in the Studio ad designer tool. We can also insert any number of tracking pixels into the VAST response and, again, can fire different trackers for different creatives.

This being a redirect tag, the response could be different for every request.


For DSPs to support the dynamic functionality, several features are required:

  • VAST redirect support i.e. firing our tag, and then following the directions of the VAST response that we provide, most importantly where to find the media asset.
  • Client header information needs to be passed to us with each request. At minimum this is IP address, Device ID (on mobile) and User Agent of the listener's device. Normally this is passed (or proxied) in the HTTP headers, although can be appended to the tag using DSP-specific macros.
  • No caching of responses or tags. As this is a dynamic tag, all of the components of the response could be different for each request, so caching does not work.
We know a test is working when the requests and impressions are spread across a region, indicating that real users are generating them.

We know a test is working when the requests and impressions are spread across a region, indicating that real users are generating them.


When we integrate with a new DSP, SSP or ad server we run a series of tests to check that dynamic audio is fully operational:

  1. Environment: you call our dynamic creative server from a test stream and we respond with an audio ad that tells you everything we know about you and the call: time, location, device type, number of impressions. This primarily checks the the User's IP and User Agent are being correctly passed in the request header, and that impression pings are being fired.
  2. Parameter passing: you pass us a set of parameters that are available at your end via macros. Again in a test stream and we mirror them back to you in the audio e.g. Segment, Gender, Genre. This checks that macros can be created and populated in the tag.
  3. Scale: we create some filler audio that you place in remnant/unsold inventory on a live stream so that we can test that calls work at scale and that our numbers line up.

We have different tags for each of these tests and can work with you at each stage to ratify the test and debug as appropriate. It is possible to roll all of the tests into one, depending on timing and how confident we are feeling - we've done a few of these now so we know pretty quickly when it is working and where the usual pitfalls are.

Analytics part 3

Analytics is a huge topic. So much so that we have broken this blog post into three.

  1. Introduction

  2. Analytics overview

  3. Individual script delivery (this post)

Individual script delivery

Below the overall campaign data, the analytics page reports individual script delivery. You can choose which script from the drop down menu. The panels show the Impressions / Complete / LTR and CTR data for that script, as the overall campaign data above did.


Next to that is a breakdown of the Top 3 operating systems (OS Types) and Device Types that have requested this script. 

The OS options include Android, iOS, Windows, Mac OS, Linux and Other (which accounts for any other operating system that we do not recognise or device / app that does not report its OS). Device types include Mobile, Tablet, Desktop, Appliance (such as home speakers or TVs) and, again, Other (for devices that we don't recognise or don't report).

Traffic breakdown: the Flow diagram

Depending on the complexity of a script, there can be thousands, if not millions of different versions of the audio. Showing all of these potential versions in one comprehensible way is difficult so we designed the flow diagram to try to show the many different routes through a script.

The flow diagram goes from left to right: zero seconds on the far left through to 30 seconds (or however long the script is) on the right. The width of each line represents the relative proportion of impressions flowing through each branch of the script.

Use the Zoom tool to see the whole chart, or focus in on the area you are interested in.

Rolling over a line in the chart shows the number and proportion of impressions that flowed through that line (101.5k (22.2%) impressions for the line "Get down to your local B&Q" as shown in the diagram above).

The rules that have been set in the script dictate how the impressions flow through that script. These are shown in the bar above the flow line. Click on a branch, or the rule at the top to see further detail for that rule.

Flow diagram zoom in

The overview charts that pop up on the right will depend on the type of rule.

Overview for location rule

Overview for location rule

Overview for weather rule

Overview for weather rule

Overview for random rule

Overview for random rule

These diagrams will depict the data that was served across your selected time frame, allowing you to see which data has been used through the script. These charts include Ignored and Default:

Default: Using weather as an example, where there are four possible choices (Sun, Rain, Cloud, Snow), if the script only contains lines for, say, Sun and Cloud, and a default line for the other conditions, then the chart will only show Sun, Cloud and Default (even though the default line might have been served to users whose weather condition was Rain or Snow).

Ignored shows that data was ignored to choose this route through the script. See the blog post on ignoring here.

Below the charts is a data table that can be sorted by number of impressions.


The blue star shows which line is the default.


  • Measure the default condition separately from the rules you have created by duplicating a line to serve as a default setting, and using the same audio.


Analytics part 2

This is part 2 of the Analytics blog series. The other posts are here:

  1. Introduction

  2. Analytics overview (this post)

  3. Individual script delivery

Analytics overview

On the main analytics page, the top bar shows campaign delivery: the overall delivery of all scripts in the campaign.

From left to right:

  1. The first number shows the number of impressions served and the blue wheel around that number indicates how far through the total that is, which is the number shown by Complete.

  2. Unique is the total number of impressions from unique identifiers that we have seen for this campaign (which can be made up of many scripts) divided by the total number of impressions. 34.4% means that each user has heard this campaign just under 3 times each.

  3. Listen Through Rate (LTR) is the total number of End tracking pings we receive divided by the number of Start pings.

  4. Click Through Rate (CTR) is the total number of clicks divided by the total number of impressions.

  5. The impression targets delivery chart shows how the campaign is delivering over time compared to the average number of impressions per day (calculated by dividing the total number of impression in the campaign by the total number of days between the campaign start and end dates). This chart is useful to quickly see if a campaign is over or under-delivering. Note, the delivery chart is not shown after the campaign end date.

The next chart shows how the different scripts in the campaign have delivered over the selected time.


If you have multiple live scripts in a campaign or have re-published scripts within a campaign (either under the same publication key or multiple publication keys) then you can see how each of those scripts has contributed to the overall delivery.

You can choose to show delivery by Campaign, Week, Day or Hour until the present moment.


The next section of data is all based on the script that you choose from this campaign.

By default, the script that has delivered the most impressions in this campaign is selected.

Our next blog post covers how we provide analytics for an individual in more detail.

The analytics story continues over at part 3, here.


Analytics part 1

Analytics is a huge topic. So much so that we have broken this blog post into three.

  1. Introduction (this post)

  2. Analytics overview

  3. Individual script delivery

Analytics Part 1: Introduction

We provide a comprehensive set of analytics tools to show you exactly how a campaign is being delivered from the moment it starts. The general principal is that the our analytics shows delivery - how impressions for that campaign or script have been served. Today we don't measure anything other than delivery as the only metrics we have are impressions (and a few clicks) - see audio measurement side bar.

There are three places to get to the data:

1. Dashboard. The dashboard card for each live script shows how many impressions have been served relative to the total impressions target and provides a quick reference impressions chart as a shadow in the background of the card.


2. The Analytics button from the main toolbar. This takes you to the analytics overview page that shows the delivery of all of the scripts currently running that your user group has access to.


Each frame contains a chart that shows delivery of impressions over time, total impressions served relative to the total impressions target of that campaign and the proportion of unique users.

Clicking the blue chart icon will take you to the individual page for that script.

3. Script icons.


Clicking the chart icon from anywhere in the interface will take you to the analytics view for that campaign or script. If a script has not been published or no impressions have been tracked then the analytics page will be blank or unavailable.

Key settings

The analytics system uses the campaign start and end dates and the impressions totals for each script.


Note: these settings in our system are purely to power the analytics: A Million Ads does not control campaign delivery. Campaign start and end dates, number of impressions, frequency capping, front/back loading, targeting and segmenting is all done at the ad server / SSP / DSP level - we simply obey the requests that come our way.

Many of the charts here will be replicating charts that you can find in other systems. We hope that our eye for nice design and usability make is preferable to use our tools over others you may have access to.

Audio measurement side bar

Audio is a hard medium to measure because it is typically consumed in a passive way: on the radio in the corner of the room, in the car, on your headphones plugged in to your mobile ... that is in your pocket. So, unlike other digital media, there are very few signals from users to measure performance (video has view-through-rate, display has click-through, desktop has cookies for attribution etc). Some audio ads are delivered with companion images that can be clicked on, and the click can be measured, but click have been widely discredited as useless, as they don't stay on beyond the audio, if there is an exit or cancel button, most clicks are false positives as people go for the cancel button and miss! We track impressions, clicks, when the ad starts playing and when playback is complete, and we display these data points in the analytics page, but it all comes with this "health warning"!

The future of audio measurement

In time, voice activation will prove to be a useful interface for users to interact with ads, but for the moment, impressions is all we have.

This is just the start of the post on analytics. Continue the story in part 2, here.


Overrides gives manual control over which scripts is played

The basis of the override feature is to allow users to manually set a piece of data in a script, effectively overriding any other data that may be around. Here is what the settings screen looks like for a script we ran recently:


We have defined a custom data field called "Walkers" and told the script to change based on the number e.g. "Over 70,000 walkers are taking part ..." is the default, but with the override set as per the screen shot, the script changes to "Over 80,000 walkers are taking part".

You can use this for things like changing a product (for example: 3 products are on sale, but one has just sold out!), price (dynamic pricing based on demand) or prize fund (this week's lottery jackpot amount).

The settings page above can be made available to the client or agency themselves, giving them real control over their creative and is much simpler than making an API connection ... once the save button is pressed the next ads served will reflect the change.

Here is an example of changing an override whilst a campaign is in flight. In this example, we change the jackpot amount of the lottery by simply changing a value in the script settings.