EINBLIQ.IO

How integration works

Your CDN ships its access logs to EINBLIQ.IO. CMCD from the player travels inside those logs, and CMCD v2 events can additionally be sent to our CMCD v2 endpoint.

Last checked

From CDN logs to playback sessions

CDN logs record segment, manifest and licence requests that pass through the CDN and are included in its logging configuration. SPECTRA groups suitable records into playback sessions, so FOCUS can discover unusual patterns as Signals and investigate each one. This works with suitable CDN logs alone, even without CMCD or an explicit session ID. Playback duration and startup behaviour derived from logs are estimates; direct player errors and stalls need player telemetry.

When your players send CMCD (Common Media Client Data, CTA-5004), each request also carries what the player reported at that moment, such as buffer length, requested bitrate and a session ID. The CDN writes these values into its log line next to the delivery data. No proprietary EINBLIQ.IO SDK is involved: CMCD is an open standard that common players already implement.

Two ways to deliver logs

S3 bucket managed by EINBLIQ.IO Direct HTTPS delivery
How it works Your CDN writes log files into a bucket we provision for you. We pick them up from there. Your CDN streams log lines to our HTTPS endpoint as they are produced.
Used with Akamai, Amazon CloudFront, Gcore, Kafka and most other CDNs Fastly
You receive from us <BUCKET_NAME>, <AWS_REGION>, a prefix or folder path and access credentials <ENDPOINT_URL> and <BEARER_TOKEN>
Delivery delay Set by the CDN’s export interval: from under a minute to several hours Near real time

Which path fits is decided by your CDN’s export options. Both paths deliver the same information to SPECTRA.

What we exchange during onboarding

From you: access to your CDN or log pipeline configuration, the services or properties to include, and where required an identifier we need to authorise delivery, such as your Fastly service ID or AWS account ID.

From us: the delivery target and credentials for your setup. The guides mark every value you receive from us as a highlighted placeholder such as <ACCESS_KEY_ID>.

Log fields we need

Field names differ between CDNs. What matters is that each log line contains these values:

Field Content
Timestamp Request time in UTC, ideally with milliseconds
Hostname Requested host
Client IP IP address of the requesting client
Edge IP IP address or identifier of the edge server
User agent HTTP User-Agent header
URI Path of the requested object
Query string Full query string, including CMCD= when present
Status code HTTP response status
Bytes Response size in bytes
Duration Time to serve the request, in milliseconds
Cache status Hit, miss or the CDN’s equivalent
Referer HTTP Referer header
CMCD (optional) Player-reported values, from the query string or captured CMCD request headers, when available

Send CMCD as a query parameter

The CMCD specification allows both transmission modes, and servers must accept either. It prefers headers where they cause no extra cost, but for browsers it recommends query parameters: custom request headers make the browser send a CORS preflight request before each new segment URL. The web players hls.js, dash.js and Shaka Player send query parameters by default.

Three settings make the query parameter work well:

  • Keep CMCD out of the cache key. CMCD values change with every request. If the parameter is part of the cache key, each request becomes its own cache entry. The specification notes the same, and each CDN guide shows the setting.
  • Keep the full query string in the log. Check that your log format includes it.
  • Check signed URLs. If your token or signature covers the whole query string, a CMCD parameter appended by the player invalidates it. The CDN guides note where this applies.

Some native players can only send headers: Apple AVPlayer uses CMCD headers exclusively, and Media3 uses headers unless configured otherwise. The player setup page lists the transmission mode of each player, and the CDN guides explain how to log headers where the CDN supports it.

CMCD v2 event reporting

CMCD v2 adds event mode: the player sends batches of events, such as play state changes, errors and periodic status reports, to a reporting endpoint, independently of segment requests. EINBLIQ.IO provides a CMCD v2 endpoint for this. We give you its address and any required token during onboarding, and you add it as the event target in your player configuration.

SPECTRA joins the events with your CDN logs through the session ID (sid) and content ID (cid). Set both explicitly and to the same values in request mode and event mode. The player setup page shows where the endpoint goes in each player.

Integration steps

  1. Tell us which CDN or log pipeline you use and which services should be included.
  2. We prepare the delivery target and send you the values for your guide.
  3. You configure log delivery as described in the guide for your CDN.
  4. If adding player context, you enable CMCD in supported players, ideally as a query parameter.
  5. We confirm that logs arrive with the expected fields and review the first sessions with you.

Guides by CDN