EdgeKit vs Piano

In its most common mode, yes, and Piano says so plainly. Its implementation checklist states that most Piano clients choose a traditional client-side Composer setup, and its Googlebot page describes that mode as the content being served in the browser and secured on the client side — in its words, covering the content. Piano’s own comparison table rates content protection under a client-side experience as visitor-dependent and only its edge and server modes as full. That is a normal trade for a hosted script, not a fault: it is fast, it needs no infrastructure, and Piano ships two modes that do withhold. What matters commercially is that those two are an additional paid option, they cannot both run on one application, edge mode carries a documented one-page delay in which a reader who has just paid is still blocked, and the worker that calls Piano is written and operated by you. EdgeKit’s equivalent is included, and it has its own ceiling — see the last answer here.

EdgeKit runs it rather than handing you a toolkit. Your reader records, their sign-in state and your billing history move across, and nobody registers again or re-enters a card — sign-in is either kept as-is, with EdgeKit verifying a token you sign and reading its claims on every decision, or replaced with EdgeKit’s own, per title. Your rules do not move: a decision graph does not transfer between engines, so they are re-authored rather than imported, and that is the work worth planning for. One limit to know rather than discover: reading access straight off your claims is how a title runs while your own identity system stays the authority for it, and a subscription arriving from a billing sync does not yet write an access record of its own, so for a title moving fully onto EdgeKit sign-in that step is ours to run with you. Worth knowing about the other direction too: Piano’s own import is run by Piano, booked two to four weeks ahead, capped at 500,000 rows a day, and a wrong import cannot be updated or cancelled.

We can only answer half of it. EdgeKit publishes every rate, with a calculator you drive with your own volumes. Piano publishes none: its pricing page answers 404 while its own terms still cite it, and the figure comes from an account manager. Its standard agreement does publish the direction of travel — an annual uplift of the greater of 7% or US CPI, on fees payable for capacity purchased rather than capacity used.

The data is yours and there is no export fee, here or in the contract. Today there is no export button and no export endpoint, so an export is us running a query for you. Where EdgeKit is deployed into your own cloud account, the database and the event archive already sit in infrastructure you control and you do not need us to reach them. Piano is ahead of us on the self-serve half: it documents a bulk user export through its API, sells Data Flow and Data Sharing as scheduled routes to the behavioural rows, and its agreement gives you a thirty-day window after termination to request a download of your data. Two things to hold it to in return, because both are published: those data routes are contract options rather than part of the base product, and after that thirty-day window Piano may delete the lot.

Be the thing a thousand publishers already run: Piano’s own about page publishes more than 1,000 clients and twelve years in business. Every row here compares the product, not the track record — weigh that separately. Two product gaps, named rather than left for you to find. Our server-side enforcement needs a body selector your page declares and an anonymous reader resolves — half the 26 paywalled sites we surveyed had one — and without it we draw a panel over a complete page. And a subscription arriving from a billing sync writes no access record yet, so on a title moving fully onto EdgeKit sign-in, we run that step with you.