Краткий ответ
Каталог игр, используемый для закупок, интеграции и операционной деятельности, должен быть больше, чем отображаемый список названий провайдеров и игр. Как минимум, он должен отвечать на пять вопросов: что это за запись, откуда она получена, какую версию она идентифицирует, каков ее текущий статус и кто и когда ее проверял. Для языка, валюты, целевого рынка, сертификации и статуса релиза также нужны отдельные поля; их нельзя свести к неоднозначному флагу «доступно».
Текущий каталог игр — это снимок на уровне названий от 7 августа 2026 года. Он содержит 11 провайдеров и 1 194 названия игр. Он полезен для первоначального поиска контента и как отправная точка для управления каталогом, однако в нем нет кодов игр, версий, математических моделей, обложек, демо, полей API, сертификаций или доступности в реальном времени. Поэтому он не может установить, доступна ли конкретная игра для проекта.
Количество и дата не меняют природы этого снимка. Они не являются доказательством поставки в реальном времени, включения в production, прав третьих лиц или доступности на целевом рынке.
Почему список названий еще не является продуктовым каталогом
Названия могут показать, какие записи были собраны, но не позволяют надежно связать запись с API, изменением версии, результатом теста или целевым рынком. Дублирующиеся названия, переименованные игры, разные скины и игры одного типа с разными математическими моделями могут сделать сопоставление по названию неточным.
Управление каталогом — это не заполнение всех полей любой ценой. Его задача — сделать каждое решение прослеживаемым до записи с источником, датой и ответственным лицом. Если значение отсутствует, корректный статус — ожидает проверки, а не предположение, основанное на сторонней странице, имени файла или прежнем опыте.
Минимальная модель данных
Эти поля могут находиться в нескольких таблицах, но их смысл и ответственность за них должны сохраняться.
| Группа полей | Минимальные поля | На какой вопрос отвечает | Рекомендация |
|---|---|---|---|
| Стабильная идентификация | catalog_record_id, provider_id, provider_game_code, game_name, game_type |
Что именно уникально идентифицирует эта запись? | Используйте стабильные ID во избежание коллизий названий |
| Происхождение | source_ref, source_type, source_snapshot_at, source_hash |
Откуда получена информация, когда и можно ли ее проверить? | Сохраняйте источник и дату |
| Версия игры | game_version, math_model_version, client_build, release_note_ref |
Какие программное обеспечение и математическая модель были проверены? | Связывайте с поставленной сборкой |
| Версия интеграции | provider_api_version, aggregator_version, integration_version |
Какая цепочка интерфейсов соответствует этой версии игры? | Записывайте полную топологию |
| Жизненный цикл записи | record_status, status_reason, effective_from, effective_to |
На каком этапе жизненного цикла находится запись? | Используйте контролируемые состояния |
| Статус среды | staging_status, production_status, demo_status, last_verified_at |
Что действительно проверено в каждой среде? | Храните каждую среду отдельно |
| Поддерживаемые измерения | language_codes, currency_codes, device_scope |
Какие языки, валюты и устройства были проверены? | Не выводите их из названия |
| Рынок и сертификация | market_code, operator_scope, certificate_ref, certificate_scope, certificate_status |
Какие доказательства относятся к определенному объекту, версии и области? | Явно сопоставляйте каждый целевой рынок |
| Права и ограничения | content_rights_scope, territory_restriction, usage_restriction, evidence_ref |
Какие ограничения применяются к отображению, демо, распространению или использованию на рынке? | Храните права отдельно |
| Ответственность и проверка | data_owner, reviewer, updated_at, next_review_at, change_reason |
Кто сопровождает и подтверждает запись и когда следующая проверка? | Сохраняйте ответственность и сроки |
Не используйте три разных идентификатора так, словно это один и тот же ID
catalog_record_id— стабильный внутренний идентификатор записи каталога; он должен оставаться прослеживаемым при изменении отображаемого названия.provider_game_code— идентификатор игры, используемый провайдером или вышестоящим интерфейсом; он должен поступать из проверяемого материала об интерфейсе или поставке.- Слаг страницы или маркетинговый псевдоним предназначен только для представления. Он не должен становиться первичным ключом для транзакций, сертификации или сопоставления версий.
Происхождение, статус, версия, обновления и ответственность
1. Происхождение должно быть прослеживаемым
Для каждого импорта сохраняйте тип источника, ссылку на расположение или документ, время создания снимка и пакет импорта. Если источник впоследствии заменен, сохраняйте период действия старой записи, а не перезаписывайте ее историю. Сторонняя страница может указывать на кандидатные данные, но не должна быть единственным доказательством прав, версии или текущей доступности.
2. Статус должен указывать объект и измерение
Контролируемый жизненный цикл каталога может использовать следующие состояния:
| Статус | Значение | Что можно заявлять публично |
|---|---|---|
draft |
Запись существует, но критически важная идентификация или происхождение не проверены | Не публиковать |
pending_verification |
Кандидатный материал существует, но доказательства проверки неполны | Указывать только, что проверка ожидается |
verified_current |
Указанная версия и среда были проверены на указанную дату | Указывать только подтвержденную область |
suspended |
Временно отключено, поскольку доказательства устарели, возникла проблема или действует ограничение | Не представлять как доступное в настоящее время |
retired |
Больше не сопровождается или заменено новой версией | Сохранять историю; исключать из текущего каталога |
«Записано в каталоге», «проверено в staging», «включено в production» и «доступно на целевом рынке» — разные состояния. Ни одно из них не подразумевает другое.
3. Изменения версии должны запускать проверку воздействия
Изменение игры, математической модели, RGS или агрегатора, API-контракта, правил валюты, языковых ресурсов или требований целевого рынка должно запускать проверку воздействия. Связывайте ее результат с обновленными доказательствами тестирования или сертификации. Не предполагайте, что вывод для старой версии автоматически переносится на новую.
4. Каждому обновлению нужна цепочка ответственности
Минимальный рабочий процесс:
- Владелец данных импортирует или предлагает изменение с указанием происхождения и причины.
- Автоматизированные проверки валидируют стабильные ID, обязательные поля, дубликаты и контролируемые состояния.
- Технические, бизнес- или комплаенс-владельцы проверяют поля в пределах своей ответственности.
- Одобрение создает новую версию или обновляет период действия без удаления исторических доказательств.
- Дата проверки, недействительный источник или критически важное изменение версии возвращают запись в состояние ожидания проверки.
- Публичные страницы используют только поля и состояния, одобренные для отображения.
Приоритеты при улучшении каталога
Не создавайте сотни подробных страниц непосредственно из списка названий. Выстраивайте работу в порядке ценности для принятия решений:
- Добавьте стабильные ID провайдеров, коды игр провайдеров, происхождение и владельцев записей.
- Добавьте версию игры, версию интерфейса и статус staging, необходимые для фактической интеграции.
- Для игр, переходящих к оценке рынка, добавьте рынок, операционную организацию, язык, валюту, объект и область сертификации.
- Добавляйте обложки, демо и описания только после подтверждения прав на активы и источников.
- Создавайте подробный контент только для игр с реальной потребностью проекта и достаточными доказательствами.
Что предоставляет текущий каталог
- Снимок на уровне названий от 7 августа 2026 года с 11 провайдерами и 1 194 названиями игр.
- Названия провайдеров и игр для первоначального просмотра и обсуждения области контента.
- Ни инвентаризации в реальном времени, ни списка production, ни репозитория версий, ни реестра прав, ни базы данных сертификаций.
- Описанная в этой статье система управления полями, состояниями и владельцами, необходимыми на следующем этапе.
Границы, о которых следует помнить
- Ни для одной указанной игры не обещается, что ее можно вызвать, запустить, открыть для игры или что она сейчас доступна в production.
- Каталог не доказывает авторизацию провайдера, права на использование активов, разрешение для целевого рынка или действительность сертификации.
- Язык, валюта, подключение интерфейса и включение в каталог не устанавливают законность на рынке.
- Не выдумывайте коды игр, RTP, версии, математические модели, обложки, ссылки на демо или ID сертификатов.
Часто задаваемые вопросы
Означает ли название игры в каталоге, что ее можно интегрировать немедленно?
Нет. Оно показывает только, что запись присутствует в исходном источнике. Для интеграции по-прежнему требуется проверить код игры провайдера, интерфейс и версию игры, статус среды, коммерческие права и условия целевого рынка.
Почему версия игры и версия математической модели записываются отдельно?
Обновление клиента или визуальной части может не менять математическую модель, тогда как изменение математической модели может потребовать нового тестирования и проверки сертификации. Отдельные поля идентифицируют объект, на который фактически распространяются существующие доказательства.
Можно ли автоматически заполнять отсутствующие поля данными с сайтов провайдеров?
Публичные страницы могут быть кандидатными источниками, но сохраняйте источник и помещайте значение в статус ожидания проверки. Используйте его для решения по проекту только после подтверждения применимым материалом, действующим интерфейсом или ответственным владельцем.
Как часто следует обновлять каталог?
Не полагайтесь только на фиксированный график. Изменение источника, выпуск версии, инцидент со статусом, истечение срока действия доказательств или изменение правил целевого рынка также должны запускать проверку.
Связанные материалы и следующие шаги
- Разберитесь с границей много-провайдерного Slots API
- Оценивайте провайдера Slots API на основе доказательств
- Создайте матрицу рынка, игры, версии и сертификации
- Используйте единообразную терминологию Slots API
- Основные страницы: каталог игр и публичная справка API
Перед использованием раздела «Связаться с нами» подготовьте целевой рынок, предлагаемых провайдеров или область игр, модель кошелька и ожидаемые среды. Затем AG сможет вернуть поля каталога и доказательства, которые нужно проверить для этой области. Это не обещает поставку, права или допуск в production.
Источники и область применения
Количество в каталоге относится только к снимку от 7 августа 2026 года. Для конкретного проекта все равно необходимо проверить статус записи, права на отображение и доказательства для целевого рынка.
Нужно превратить это руководство в план проекта?
Материал помогает оценить проект, но не заменяет техническое, договорное, сертификационное или правовое подтверждение.