Для повністю нового бізнесу порівняйте white label і turnkey. Для sportsbook у наявній платформі розгляньте інтеграцію API.
Простежте одну ставку через платформу
Почніть із події, ринку та вибраного результату, показаних гравцеві. Запит на розміщення має зберігати відповідні коефіцієнт і контекст правил. Потім приймання має узгоджуватися з гаманцем і рішенням щодо ризику; запит, надісланий інтерфейсом, не доводить, що ставку прийнято.
Під час розрахунку простежте джерело результату та правило, застосоване до позиції. Якщо результат виправлено, збережіть початковий розрахунок і коригування, щоб пояснити підсумковий баланс гравця. Ті самі ідентифікатори мають використовуватися в інтерфейсі гравця, розслідуванні підтримки та фінансовому звіті.
Запитайте цей покроковий розбір у конфігурації, яку плануєте придбати. Екран із коефіцієнтами та балансом не демонструє звірки між ними.
Порівнюйте функції з фактичним каталогом запуску
| Функція | Питання для демонстрації |
|---|---|
| Ставки до початку події та під час гри | Які пріоритетні змагання й ринки підтримуються та коли їх призупиняють? |
| Ординари, експреси та системи | Як відхилені вибори, анульовані компоненти й переглянуті результати впливають на решту ставки? |
| Конструктор ставок | Які комбінації дозволено для відповідних зустрічей і постачальника? |
| Cash-out | Коли пропозиція може змінитися або зникнути та що підтверджує завершення її прийняття? |
| Контроль ризиків | Які ролі можуть змінювати ліміти, робити виняток із правила або погоджувати ручний розрахунок? |
| Спільний обліковий запис гравця | Як верифікація, ліміти й виключення передаються до кожного підключеного продукту? |
| Трансляції та трекери | Які права, території й інтерфейси входять до запропонованої послуги? |
Погоджуйте обмеження постачальника або ринку разом із відповідною функцією. Загальний розмір каталогу не відповідає на питання, чи охоплено найважливіше для вас змагання.
Оберіть межі фронтенду
Вбудований sportsbook може скоротити роботу з інтерфейсом, за яку відповідає ваша команда, але інтеграцію, стан облікового запису та звітування про події ще потрібно погодити. API покладає на команду більше відповідальності за сценарій гравця, зокрема зміни коефіцієнтів, затримки відповідей і помилки.
Обирайте відповідно до досвіду гравця, який потрібно контролювати, та інженерних ресурсів для його підтримки. З’ясуйте, які акції, аналітичні події, процеси автентифікації та мобільні сценарії підтримує кожен варіант. Посібник із моделей інтеграції містить основу для порівняння.
Відокремте заплановану маржу від фактичного hold
Маржа, закладена у запропоновані коефіцієнти, та результат після розрахунку ставок — різні показники. Фактичний hold зазвичай обчислюють як валовий ігровий дохід, поділений на суму розрахованих ставок за визначений період. Наприклад, €50 000 GGR на €1 000 000 розрахованих ставок — це 5%, до врахування витрат, які не входять до цього визначення GGR.
Порівнюючи звіти, використовуйте однакові правила щодо анулювань, нерозрахованих позицій, акцій і конвертації валют. Зміна hold може відображати результати, структуру ставок, акції або операційні проблеми. Одна функція платформи не встановлює причини й не гарантує певної маржі.
Відпрацюйте збої до вибору конфігурації
Перевірте зміну коефіцієнта під час розміщення, невизначену відповідь після резервування коштів, переривання фіду та виправлений результат. Для кожного сценарію встановіть очікуване повідомлення гравцеві, стан ринку, запис гаманця й дію працівника.
Якщо запропоновано резервний фід, перевірте зіставлення подій і відновлення, не припускаючи автоматичного перемикання кожного ринку. Наявні ставки все одно мають бути розраховані за застосовними до них правилами та джерелом результату.
Запитайте демонстрацію конфігурації, зазначивши ринки, пріоритетні змагання, поточний гаманець і бажану модель трейдингу. Додайте сценарії збоїв, які ваша команда має вміти розслідувати.