What Data to Track After Launching an Interactive Film Game: Choice Rate, Completion Rate, Replay Rate, and Ending Distribution

After an interactive film game launches, view counts only show that its entry point has been opened. The data that can actually improve the work is: which nodes players reach, whether they submit choices, whether they continue after choosing, whether they return to explore another path, and whether the ending distribution matches the design intent.

The minimum events include: story_start, node_enter, choice_impression, choice_submit, node_complete, ending_reach, and replay_start. Each event carries an anonymous user or device identifier, session, work version, node, branch, and timestamp.

Session timeout rules must be clear, such as ending a session after 30 minutes of inactivity. Otherwise, a user returning the next day could incorrectly be counted as one extremely long viewing session.

Node reach rate = unique sessions reaching a node / sessions starting the work. Use it to locate drop-off, but consider the previous node's duration and loading errors as well.

Choice submission rate = choice submissions / choice impressions. A low value may result from confusing wording, obscured buttons, countdowns, or technical failures.

Choice rate = submissions for a particular option / all submissions at that node. It describes the distribution and does not directly indicate which option is better.

Completion rate = reaches of any ending / starts of the work. Break it down by version, device, and source.

Replay rate = users who re-enter a valid branch within the observation window after completion / users who complete the work. Do not count accidental refreshes or reconnection recovery as replays.

Regret rate: the proportion of players who quickly go back or restart a nearby node after choosing. This may indicate regret, but it may also indicate an accidental button tap; check it alongside dwell time and device information.

Ending distribution: the proportion of users who complete the work accounted for by each ending. Excessive concentration may mean the design has an obvious optimal solution, or that other paths have bugs; for endings reached by very few users, check whether the prerequisites are too strict.

If many players drop off before a choice point, first check pacing and loading; if they see options but do not submit a choice, check the UI and wording; if almost nobody selects an option, check whether it appears unconditionally worse; if replay is low, check whether a second playthrough provides new information and whether tools for revisiting content are available; if endings are unusually concentrated, check state and hints.

Display the funnel, node heatmap, choice distribution, ending distribution, and 7/30-day replay metrics by work version. Every metric should display its sample size, and small samples should not produce exaggerated conclusions. Also distinguish internal testing, creator previews, and real users.

Competitors generally do not publicly disclose this internal data, so this article offers methodological recommendations and does not represent any platform's actual performance. DramaFork should standardize its event dictionary from the first version to avoid discovering, after its collection of works grows, that historical data cannot be compared.

Each event should contain at least the event name, anonymous subject, session, work and version, node and option, client timestamp, server receipt timestamp, device, and source. State values do not require uploading the full story or user input; necessary enumerations, hashes, or outcome categories can be recorded instead. Event names and field types should form a versioned data dictionary, with compatibility methods explained when changes are made.

Duplicate submissions, offline caching, and retransmission after disconnection can record one choice multiple times. Generate event IDs on the client and perform idempotent deduplication on the server; determine chronological order using both server timestamps and a monotonic sequence. Creator previews, automated tests, and production traffic must carry an environment field, or internal clicks will contaminate the work's metrics.

When node reach declines, first check whether the preceding segment is too long, whether there are media errors, or whether path conditions make the node unreachable; when choice impressions are high but submissions are low, check for obscured buttons, wording comprehension, and time pressure; when many players exit after submitting, check whether the outcome conflicts with what the option promised; when replay starts are high but end quickly, there may be insufficient skipping of previously viewed content, or new content may appear too late.

Ending distribution must display both the prerequisite paths leading to each ending and the sample sizes. If only one percent of users reach an ending, it may be a hidden reward or a bug in the conditions; design goals determine whether this is abnormal, and uniformity should not be pursued mechanically.

Logs can tell the team where changes occur, but cannot explain why on their own. For anomalous nodes, review error logs, available anonymous action sequences, and user interviews, and ask players what they saw, what they expected, and why they left or restarted. Do not directly turn correlations into script-level causation, or use percentages from small samples to manufacture certainty.

For privacy, follow the principle of data minimization: collect only the fields needed to improve the experience, explain their purpose and retention period, restrict access, and establish processes for deletion and export requests. Free text and generative conversations carry higher risks and should not enter ordinary analytics tables by default. A useful dashboard calculates accurately and also helps the team understand which data should never be collected.