URL-адреса для видалення облікового запису, яку вимагає Google Play

Якщо ваш застосунок дає змогу створити обліковий запис, Google Play просить два шляхи для його видалення: один усередині застосунку і публічно доступну вебадресу, де можна подати той самий запит. Вебадресу ви вказуєте в Play Console у розділі App content → Data deletion, і довідка Google Play зазначає, що вона “must be functional (for example, loads without error), relevant in scope” (переклад: «має бути робочою (наприклад, завантажуватися без помилок), відповідною за змістом»). Скористатися нею має змогу і той, хто вже видалив застосунок.

Це вимога одним абзацом. Решта цієї сторінки — про те, що має робити сама сторінка, і про помилки, через які подання повертають.

Тут просять про дві речі, і їх легко сплутати:

1. Публічну сторінку, де можна подати запит.
2. Справжнє видалення даних у ваших власних системах, коли надходить запит.

Перше — це питання хостингу. Друге — лише ваше, і жоден сервіс не може зробити це за вас: хто стверджує інакше, не має доступу до вашої бази даних.

Що сторінка має дозволяти користувачеві

Вимога написана з погляду користувача, тож і читайте її з цього погляду. Людина, яка видалила ваш застосунок, забула пароль або ніколи його не мала, однаково повинна мати змогу відкрити сторінку і попросити вас видалити її обліковий запис.

Це виключає деякі поширені варіанти:

• Сторінка за входом в акаунт. Якщо для запиту на видалення треба увійти, ті, кому це найімовірніше потрібно, не зможуть нею скористатися.
• Лише шлях усередині застосунку. Шлях у застосунку теж обов’язковий, але він не замінює вебадресу: до неї можна дістатися зі сторінки застосунку в магазині, навіть якщо застосунку вже немає.
• URL-адреса, що повертає 404. Саме на цьому реально ловлять, бо перевірити це елементарно.

Сторінка має пояснювати, які дані видаляються, які зберігаються і як довго (платіжні записи часто треба зберігати за законом), а також скільки часу займає видалення.

Де помиляються: отримання запиту

Сторінки, яка показує форму, самої по собі недостатньо — запит має дійти до вас.

Це єдина частина, з якою простий файловий хостинг сам не впорається. GitHub Pages, бакет за CDN: вони віддають файли, але не можуть прийняти POST. Більшість хостингів, які розробник справді вибрав би, це вирішують — Cloudflare Workers, функції Netlify і Vercel, Netlify Forms, — тож це питання налаштування, а не глуха стіна. Але щось має приймати запит, і звичайний шлях «зроби сам» закінчується одним із чотирьох варіантів:

• адреса електронної пошти, надрукована на сторінці, і ніщо не заважає її зібрати ботам;
• сторонній сервіс форм, який тепер бачить адреси електронної пошти ваших користувачів;
• edge-функція на вашому хостингу — кілька рядків, але це вже код, який ви підтримуєте в кожному застосунку;
• невеликий сервер, який треба тримати запущеним заради, можливо, двох запитів на рік.

Що б ви не вибрали, вирішуйте свідомо. Сторінка видалення, яка мовчки губить запити, гірша, ніж її відсутність: ви кажете користувачеві, що його запит отримано.

Ведіть облік

Що б ви не побудували, ведіть журнал запитів: адреса, дата, що ви з цим зробили. Якщо регулятор або магазин колись запитає, «ми видалили» — це твердження, а список із датами — це доказ.

Що тут робить AppFoyer

Ми розміщуємо сторінку і пересилаємо запит. Користувач подає його, ми зберігаємо його як ваш журнал аудиту і сповіщаємо вас — електронною поштою на будь-якому тарифі або через Telegram чи Slack на платному. Видалення у власних системах виконуєте ви — ми не маємо до них доступу і ніколи не стверджуємо протилежного.

Ця сторінка залишається онлайн, навіть якщо ви перестанете нам платити, бо ваші користувачі тут ні до чого.

Авторитетне джерело

• Надання інформації про видалення даних — довідка Google Play. Прочитайте її перед поданням; вирішує саме та сторінка, а не ця.