MediaTailor server side tracking

Hi Djole91, thanks for posting this question!

Client-side reporting allows for very granular reporting as it's the player that responds with what the user has actually watched. If you review the examples at https://docs.aws.amazon.com/mediatailor/latest/ug/ad-reporting-client-side.html you'll note that each beacon event can report against a specific 'startTime' or 'startTimeInSeconds' - so the reporting can be quite detailed.

For Server-side reporting however, the server doesn't have the same granularity and has to make a best judgement based on what segments have been egressed. The reporting accuracy is therefore dependent on the full length of the Ad, as well as the segment length of that Ad, which in this case MediaTailor defaults to 2 seconds. To give you an example:

• To serve a 10 second Ad where the segment length is also 10 seconds, you would only need to pull one segment for the server to assume that the Ad had been played in its entirety. The server would get all the reporting beacons in one go. Please note this is just an example - MediaTailor doesn't serve Ads with 10s segment lengths using the dynamic transcode profile.
• To serve a 10 second Ad where the segment length is 2 seconds, the start beacon would be fired with the first segment; the midpoint would be with the third segment, and the complete beacon with the fifth segment. You would see a beacon timestamp with ~2s accuracy.
• To serve a 30 second Ad where the segment length is 2 seconds, the start beacon would be with the first segment; the midpoint with the 8th segment; and the complete beacon on the 15th segment. You would see a better timestamp representation because the ad content is longer, but still up to 2s accuracy determined by the ad segment length. If the client only egressed segments 1-8 then you would receive the start and midpoint beacon, but not the third quartile or complete beacon.

In summary, dynamic transcode profiles will create 2 second ad segments and therefore the accuracy for server-side beacons will only ever be accurate to 2s. You will see better beacon timestamp accuracy in longer Ad content because it is made up of more segments which can be reported against. If you require more detailed beacon reporting I would consider using client-side reporting.

I hope this answers your question but please let me know if you have any outstanding questions!

Hey bmarshallataws, thank you for a very thorough response. It was very helpful.

I do have one follow-up question.
Since HLS is native on IOS, i cannot control the amount of segments that are going to be buffered. It will do it's own thing.
How would you tackle this specific situation? Are there maybe configuration settings that could be useful?

Hi Djole91, you're very welcome. That is a great question... this is largely out of our control. Different players will have different logic for how many segments to buffer relative to the play head. DASH has the concept of suggestedPresentationDelay which can influence the presentation delay and how many segments the player will buffer - but this assumes the player in question is designed to look at this value and use it.

In this case server-side reporting reports purely on what the server is doing. If the player downloaded those segments to its buffer, but the user closed the browser before the ad actually played, server-side reporting would still report the Ad as viewed. From the server's perspective the segments have been downloaded and therefore the ad was viewed. For reasons mentioned above, shorter Ads will be more susceptible to this as an entire short Ad could theoretically fit in the player's buffer.

In short, to guarantee accuracy it is best to implement client-side reporting so the client can directly send accurate impression beacons based on how much of the Ad was actually viewed.

Hey bmarshallataws. Thanks for your feedback, it helped me a lot. Take care.

Glad I could help! You take care too. Best regards.