Google Play Release & Review Watch

Connect Google Play releases with recent review observations and developer replies. Track up to 10 Android apps per run, with a country and language for each watch.

Every successful app check produces a summary, including unchanged checks. Repeat runs compare public release metadata, review text, ratings and developer replies against persistent history. Reviews retain the app version supplied by Google Play. The current listing version is shown separately.

Start a watch

1. Enter Android package names, such as org.wikipedia.
2. Select country and language codes, such as us and en.
3. Choose a recent review window from 0 to 200. Use 0 for release checks.
4. Give each independent watch a unique historyStoreName. Keep the same name on repeat runs.

The default checks Wikipedia in the United States in English and observes up to 50 recent reviews. originalRatingCount and originalWrittenReviewCount are source totals; returnedReviewCount counts only the reviews returned by this run. Country selects the requested Google Play storefront; review language selects the requested source review language.

Output and history

• app_check: one complete summary per successful app, including exact public listing version when supplied, release timestamp, observed changes and coverage.
• release_changed: a change in version, release timestamp or release notes.
• review_observed and review_new: baseline or newly observed reviews within the selected recent window.
• review_changed: changes to previously observed text, rating or source version fields.
• developer_reply_changed: changed public reply text or reply timestamp.
• source_error: a failed check, reported separately from successful checks.

The recent review window is a bounded observation, not a full review archive. Missing reviews never produce deletion events. A first run establishes the baseline. History retains up to 1,000 observed review IDs per app, country and language, in the named store. Separate watches should use separate store names. Run each watch sequentially. Event IDs support downstream deduplication when a delivery is retried. Changing the review-window size starts a separate baseline, so previously unseen older reviews are baseline observations.

Run limits: 10 apps, 200 recent reviews per app, 4 review pages per app, 50 source requests, 4 MiB per source response and a 120-second source deadline. Source errors do not update that app's history. Read SUMMARY in the run key-value store for coverage and counters.

Example workflows

Ready input files in examples/ cover Wikipedia release checks, review and reply monitoring, a two-app competitor watch, and a German storefront watch.

Русский

Актор отслеживает публичные релизы Android-приложений, изменения свежих отзывов и ответов разработчиков в Google Play. Каждый успешно проверенный объект получает строку результата, даже если ничего не изменилось.

Укажите названия пакетов, страну, язык и окно до 200 свежих отзывов. Для повторных запусков сохраняйте одинаковое имя historyStoreName; независимым наблюдениям задавайте разные имена. История разделяется по приложению, стране и языку. Точная версия отзыва сохраняется только когда её сообщил источник; версия текущей карточки показана отдельно.

Первый запуск создаёт исходное состояние. Число рейтингов и письменных отзывов в источнике не равно числу отзывов, полученных за запуск. Пропажа отзыва из ограниченного окна не считается удалением. Сводка SUMMARY показывает успешные проверки, ошибки источника и объём запросов.

Billing and delivery

Complete app checks use the live Pricing section when custom-event pricing is enabled. Failed or incomplete checks are not charged. Review/change rows have no separate charge. The run checks the available spending limit before source requests. A persistent per-run billing journal prevents automatic repeat charges after an uncertain delivery; inspect SUMMARY and BILLING-JOURNAL before recovering that run.

Runtime allocation

Use 256 MiB memory. Higher allocations are rejected before initialization and source requests; the run fails with RUNTIME_UNSUPPORTED in its log. Processing has a 165-second internal deadline and a 180-second process limit, including worker shutdown. Raising the platform timeout does not extend this limit.