5. Pilot
Shape
One game, one channel, a fixed window, and a number agreed before it starts.
Engineering, on your side
| Days | |
|---|---|
| Socket client: connect, publish catalog, receive intent | 1–2 |
| Apply intent in game, draw the countdown into the video | 1–3 |
| Token endpoint in your backend (shape B only) | 0.5 |
| Viewer UI (shape B only; ours can be embedded instead) | 2–5 |
Two to four weeks end to end is a realistic pilot, most of it yours, and most of that in the game rather than the wire.
On our side
- Tenant slug and secret, exchanged out of band.
- A channel, and your catalog reviewed for cost and cooldown sanity.
- A staging tenant so nothing touches live balances.
What gets measured
Both sides should agree these before starting, because arguing about the denominator afterwards is how pilots end badly.
- Interaction rate. Viewers who acted, over viewers who were in the room and
could have. Attendance is recorded, so the denominator is real rather than reconstructed.
- Watch time, with and against a comparable window without the layer.
- Return rate at 24 and 48 hours.
- Actions per viewer, and where they cluster in a session.
All of it comes out of the event log, and the log is hash-chained, so the numbers can be recomputed and checked by either party rather than taken on trust. That is the point of building the chain before there was anything to anchor.
What we ask
- No exclusivity for a pilot.
- A named engineer on your side. Integrations die in ticket queues.
- Agreement to publish the result if it works, and to say nothing if it does not.
What happens after
If the numbers hold, the conversation is a rev-share on measured lift, and the first thing built is the SDK for your engine, because by then it will be the only thing still slowing an integration down.
Part of the IMPAKT crowdplay integration pack. All documents.