Analytics

Before enabling automatic capture, write down the decision you need to make, the least data that could inform it, who can see it, how long it is kept and how it is deleted. A pseudonymous identifier does not make a history anonymous.

A smaller event can still answer the question. To learn whether a new player reduces failed starts, the playback result, error category, app version and network class are enough, aggregated promptly and kept briefly. Leave out prayer text, chat messages, names, precise location and passage history. Even that schema is not automatically anonymous: check what the vendor’s kit adds, how IP addresses and device identifiers are handled, and what crash reports attach. A privacy label is only credible if the actual payload matches it.

When someone chooses “Report this answer”, show exactly which messages and attachments will be included, offer to remove personal details, and say who reviews it, why and for how long. Keep quality review apart from a request for urgent help, and don’t imply that reports are continuously monitored.

Restrict and audit staff access. Plan deletion across storage, logs, vendors, backups and anything derived from the data, and explain what deletion can and cannot achieve, including data already used for training. Redaction misses indirect identifiers and other people’s details, so use synthetic conversations for routine development, and set up a separate, justified process if real samples are truly needed.

Disable recording of sessions by default on chat, prayer journals, pastoral support, payments and sign-in. Test masking of rendered answers as well as typed input, and of the clipboard, accessibility labels, network requests and error attachments. A vendor’s default masking needs checking, not trust.