What this does
Akamai DataStream 2 ships near-real-time request logs from your Akamai properties to a destination of your choosing. We point that stream at Searchable’s tracker endpoint, classify the AI bots at the edge, and drop everything else. No code changes — all configuration happens inside Akamai Control Center.Prerequisites
Setup
Generate an integration token in Searchable
- Open your Searchable dashboard
- Go to LLM Analytics → Setup
- Pick Akamai as your crawler source
- Click Generate token
sa_… and won’t be shown again. You can always generate a new one if you lose it.The endpoint URL is fixed:Open the DataStream 2 wizard
Searchable LLM Analytics and assign it to the group that contains the property fronting your domain. Pick the property that serves the traffic you want Searchable to see — DataStream is scoped per-property, not per-account.Set the log file format to Structured JSON
Pick the data sets (log format fields)
UA is capitalised (it is not reqUserAgent), and the sub-country admin region is state (not region).Select all of these:reqIDreqMethodreqHostreqPathUA(capital — notreqUserAgent)statusCodecliIPreqTimeSecreqEndTimeMSec
reqID, reqMethod, reqHost, reqPath, UA, statusCode, cliIP, or reqTimeSec. reqEndTimeMSec is optional in the strict sense — a record without it is still ingested — but tick it anyway: it’s what populates response time in your dashboard.Recommended additions (used for enrichment + debugging; missing fields don’t break the integration):queryStrreferer(HTTP-standard single-r spelling)rspContentLenturnAroundTimeMSec(time-to-first-byte in ms)cacheStatuscountrystatecityedgeIPtlsVersion
reqId (lowercase d) and all numeric values as JSON strings. Searchable accepts either casing (reqID or reqId) and coerces the strings, so you don’t need to do anything special on your end — just tick the field as Control Center labels it.reqTimeSec vs reqEndTimeMSec: despite the suffix, reqEndTimeMSec is a duration (how long the request took, in ms), not a wall-clock value. The actual epoch timestamp is reqTimeSec (epoch seconds). Searchable uses reqTimeSec for the event time and reqEndTimeMSec for response_time_ms — both fields are useful and we capture both when present.Configure the HTTPS delivery
Content-Encoding: gzip automatically and our endpoint decompresses on the way in.Set the upload frequency
Validate and activate the stream
GET to the endpoint URL and expects a 200 response — Searchable’s tracker responds with a literal ok. If validation fails, see Troubleshooting below.Once validation succeeds, click Activate. Akamai activation typically completes within a couple of minutes on Staging and 5–10 minutes on Production. Once active, expect events in Searchable as soon as an AI bot hits your site.Verifying the connection
In Searchable:- Go to LLM Analytics → Setup
- Look at the Akamai card status
- Click Check if it still shows “Waiting for first event”
204 responses.
What Searchable receives
For each request that matches an AI-bot user agent, Searchable receives:- HTTP method, path, and host (query strings stripped before storage)
- User agent
- Referer
- Country, state, and city (from
country/state/city) - Response status and bytes out (
rspContentLen) - Edge turnaround time (
turnAroundTimeMSec) - Akamai edge metadata (
edgeIP,tlsVersion,cacheStatus) — preserved ascustom_propertiesfor debugging - The DataStream 2
reqID— used as the dedup key on our side
User-Agent / Referer, cookies, and full IPs are never sent or stored. The DataStream 2 reqID is hashed into a deterministic event ID so retried batches collapse into a single event server-side.
Troubleshooting
Validation fails on 'Validate and save'
Validation fails on 'Validate and save'
GET against your endpoint URL and expects 200. The two common reasons it fails:- Typo in the URL — the correct value is exactly
https://tracker.searchableanalytics.com/v1/akamai-logs. No trailing slash, no path suffix. - A custom Akamai delivery network policy is blocking egress to
tracker.searchableanalytics.com. In strict environments this surfaces as a connection error rather than a 4xx. If you suspect this, ask your Akamai admin to allow-list that hostname for the delivery property.
Validate and save only verifies that the URL is reachable. Auth issues surface in the Monitor tab after the stream activates.Searchable shows 401 errors or the card stays 'Not connected'
Searchable shows 401 errors or the card stays 'Not connected'
- Make sure you added a custom HTTP header named exactly
X-Searchable-Token - The value must be the raw
sa_…token with noBearerprefix, no quotes, and no leading or trailing space. A value ofBearer sa_…will fail — paste the token on its own - Confirm the Authentication dropdown is set to None — picking Basic there overrides the custom header
- If you’ve recently revoked the token in Searchable, generate a new one and update the stream’s custom header (no need to recreate the stream)
401 responses are the visible symptom — fix the header and the next batch will succeed. A 403 instead means the header arrived but the token failed signature verification: it’s truncated, from a different environment, or has been revoked.Akamai's Monitor tab shows 4xx responses
Akamai's Monitor tab shows 4xx responses
401 Unauthorized— the token header is missing or malformed; see the section above.403 Forbidden— the header arrived but the token failed verification (truncated, revoked, or from a different environment).413 Payload Too Large— the batch exceeded Searchable’s 5 MB payload cap. This is rare on default frequency settings (30s / 60s); if you see it, lower the upload interval rather than raising file sizes.
Akamai's Monitor shows successful 204 responses but no events appear in Searchable
Akamai's Monitor shows successful 204 responses but no events appear in Searchable
204s and produces nothing.2. Every required field is selected:reqID,reqMethod,reqHost,reqPath,UA,statusCode,cliIP,reqTimeSec
UA is capitalised and is not reqUserAgent. After missing UA, the most common single-field cause is missing reqTimeSec: without it the record is dropped outright.If the format is right and all required fields are present, the next most common cause is a domain mismatch — see “Status stays on ‘Waiting for first event’” below.I ticked reqEndTimeMSec instead of reqTimeSec
I ticked reqEndTimeMSec instead of reqTimeSec
reqTimeSecis the wall-clock timestamp of the request (epoch seconds). This is what Searchable uses to place the event in time, and it is required — a record without it is dropped.reqEndTimeMSecis a duration — how long the request took to process, in ms — not a wall-clock value despite the name. Searchable uses it for response time only.
reqEndTimeMSec, no events reach your dashboard at all, because every record fails the required-field check.Fix: open Data sets, tick reqTimeSec, and save. The stream re-activates in place and the next batch arrives correctly.Events look deduplicated incorrectly (many requests collapse to one row)
Events look deduplicated incorrectly (many requests collapse to one row)
reqID is populated with a non-unique value, or reqID was omitted from the field selection altogether.- Open the stream’s Data sets step and confirm
reqID(capitalID) is selected — Akamai’s UI lists it alphabetically near the bottom of the request-section fields reqIDis Akamai’s per-request unique identifier and is auto-populated; no property-level VCL or PMUSER variables required- If
reqIDis selected and you still see this symptom, contact support and include a few sample records — most often this turns out to be a property-level override blanking the value
reqID, Searchable falls back to a (timestamp, path, user-agent) heuristic that’s much coarser. The fix is non-destructive — add reqID and republish.Timestamps look wrong (events appear in 1970, or far in the future)
Timestamps look wrong (events appear in 1970, or far in the future)
reqTimeSec — epoch seconds, which Searchable converts to milliseconds on ingest. reqEndTimeMSec is a duration, not a timestamp, and is never used to place an event in time.If timestamps look wrong, the usual cause is a property-level override rewriting reqTimeSec, or a stream config copied from a much older DataStream 1 export that maps a different field into that slot. Confirm reqTimeSec is ticked in Data sets, then contact support with a few sample records if it persists.Status stays on 'Waiting for first event' for more than 24 hours
Status stays on 'Waiting for first event' for more than 24 hours
- The stream isn’t activated — open the stream in Control Center and confirm the status badge reads Active, not Inactive or Pending activation. Activations on Production take 5–10 minutes
- Your domain in Searchable doesn’t match the host the Akamai property serves (check LLM Analytics → Setup → Confirm your domain)
- The Akamai property fronts a different host than the one you’re testing with — DataStream is scoped per-property, so traffic going through a different property won’t appear
- No AI bot has visited yet — try visiting your site with a known AI user agent (e.g.
Mozilla/5.0 (compatible; GPTBot/1.0)) to trigger a test event
204 responses but Searchable still says no events, the issue is almost always a domain mismatch on the Searchable side.I want to test the stream against staging before flipping production
I want to test the stream against staging before flipping production
<your-host>.edgesuite-staging.net or via a Pragma: akamai-x-cache-on header trick from your origin). Successful staging delivery is a strong signal the production activation will work as well.You’ll see events arrive in the same Searchable project — there’s no separate staging endpoint to worry about.Multi-site and region-level properties (domain mapping)
A single Akamai property sometimes serves traffic for many different hostnames — for example, a region-level property that frontsexample.co.uk, example.de, and example.fr. With a standard integration token those requests would all land on one Searchable project. Domain mapping lets you route each hostname to the right Searchable project from a single DataStream stream, without touching the Akamai config or reissuing the token.
How it works
- In Searchable, go to LLM Analytics → Setup and open Domain mappings.
- Create a mapping and add host rules — one rule per hostname your Akamai property serves (e.g.
example.co.uk→ the UK project,example.de→ the German project, and so on). - Generate a domain-mapping token from the same manager. The token looks the same as a standard
sa_…integration token and goes in the sameX-Searchable-Tokenheader, raw and with noBearerprefix. - Paste the token into your DataStream’s Custom HTTP header field (replacing any existing token).
reqHost field of each incoming log record and routes it to the matching project. Hostnames that have no rule are silently discarded — they are never stored. Rule changes propagate within about a minute; you don’t need to touch the Akamai stream or generate a new token.
Diagnostic events
DataStream diagnostic envelopes from a mapping token are not attributable to a single project and are dropped in the current release. If you need per-batch ingestion diagnostics, use a standard (single-project) integration token instead.Removing the integration
To stop sending traffic to Searchable:- Akamai → CDN → DataStream → your stream → Deactivate (and optionally delete the stream once it’s deactivated)
- Searchable → LLM Analytics → Setup → Tokens → revoke the token
401, which Akamai will retry and then drop).