A cache key answers a deceptively important question: which requests are allowed to share a response? If the answer ignores something that changes the content, the cache can serve the wrong representation very efficiently.
I would review correctness before hit ratio. A faster response is not a success if it belongs to another locale, account state, or experiment.
Separate representation from tracking
Consider /catalog?locale=fr&campaign=email. If locale changes the language but campaign only records attribution, the two parameters have different roles. Ignoring both can mix languages. Including every tracking variation can fragment the cache and increase origin traffic.
Akamai’s cache-key query-parameter behavior supports explicit inclusion or exclusion choices. Those choices must follow how the application constructs its response; the edge cannot infer that contract from the parameter name.
For authenticated or personalized content, start by establishing whether shared caching is appropriate at all. A cookie being present is not a complete caching policy. Review origin headers, edge behaviors, and the actual response variation together.
Test pairs of requests
I like a pairwise test because it exposes the assumption directly. Make two requests that should share content, then two that must remain distinct. Compare both the body and relevant cache behavior. Run the test cold and warm.
For example, two campaign values might be equivalent for catalog content, while two locale values must differ. Use test identities and synthetic data for any account-dependent case. Do not validate privacy boundaries with real customer records.
A key change is also a capacity change
Changing keys across a large property can make existing cached objects unavailable under the new keys. Akamai explicitly warns that this can drive a surge of requests to the origin. Plan capacity and observation for that transition rather than only comparing steady-state cache ratios.
Watch origin request rate, latency, errors, and the affected paths. If the deployment changes key cardinality, explain the expected direction before launch. A sudden drop in hit ratio should have a hypothesis attached to it.
The useful review question is simple: what proves these two requests deserve the same response? If nobody can answer it, the cache policy is still a guess.