Симуляція мобільного відбитка змушує desktop-браузер представлятися мобільним пристроєм. Екран, модель пристрою, сенсори й touch, мережа й оператор, а також ідентифікатори UA/App мають бути узгоджені між собою, щоб середовище виглядало правдоподібно під час перевірок.
Під час ведення реклами та акаунтів на платформах на кшталт Facebook, Instagram і TikTok багато дій на мобільних пристроях і desktop поводяться по-різному: відрізняється макет сторінок, точки входу до функцій і підхід платформи до мобільного трафіку. Щоб перевіряти такі сценарії без великої кількості реальних телефонів, desktop-браузер має представлятися мобільним пристроєм.
На словах це звучить просто, але на практиці потрібно узгодити цілий набір параметрів. Надійність мобільного середовища залежить від того, наскільки логічно ці параметри поєднуються між собою.
Чим mobile відрізняється від desktop
Найочевидніша різниця — екран. Логічна роздільна здатність і ширина viewport на мобільних пристроях значно відрізняються від desktop, а доступний viewport навіть для однієї моделі може змінюватися між версіями системи. Якщо параметри екрана не збігаються, інші налаштування теж виглядатимуть неприродно.
Другий рівень — модель пристрою та клас апаратної частини. Платформа може використовувати модель, щоб оцінити категорію пристрою, а потім вирішити, яку версію сторінки або матеріалу показати. Модель, pixel ratio, пам'ять і графічні параметри мають відповідати одне одному. Назва флагманської моделі в поєднанні з характеристиками бюджетного пристрою сама по собі суперечлива.
Сенсори та touch-характеристики — один із рівнів, які найлегше пропустити. Реальні смартфони мають гіроскоп і акселерометр, а touch events можуть містити тиск, площу контакту та multi-touch, чого desktop-браузер за замовчуванням не має. Якщо змінити лише UA на мобільний, перевірка touch events може швидко показати невідповідність. Тут важливі узгоджені показники сенсорів і форма touch events, а не просто ввімкнення кількох опцій.
Тип мережі та оператор також є частиною відбитка. Мобільні пристрої зазвичай використовують стільникову мережу, а сторінка може читати назву оператора, тип з'єднання або навіть дані, пов'язані із сигналом. Якщо середовище заявляє конкретного оператора в певній країні, але вихідне з'єднання використовує IP дата-центру, така комбінація нетипова для реального пристрою й потребує окремої перевірки.
Останній рівень — user agent та ідентифікатори пристрою, і для багатьох це єдине, що змінюється. UA має відповідати моделі пристрою, версії системи та версії браузера. Ідентифікатор WebView у App та ідентифікатор звичайного браузера — це також різні речі; платформа може за ними визначати, чи візит відкрито з App, чи безпосередньо з браузера. Змішування двох типів залишає ознаки штучно складеного середовища.
Як перевіряти узгодженість
Після налаштування параметрів краще пройти перевірку в сталому порядку. Порядок важливий, оскільки проблема на ранньому етапі може виглядати як проблема на пізнішому.
Спочатку перевірте ідентичність пристрою: чи відповідають операційна система, модель, роздільна здатність і pixel ratio, які бачить тестова сторінка, заданій конфігурації, а також чи збігаються модель і версія системи в UA з цими значеннями. Потім перевірте часовий пояс і мову. Вони мають відповідати цільовому ринку акаунта, а геолокація та регіон вихідного з'єднання повинні бути в одній зоні; суперечності між цими даними є поширеним сигналом. Далі перевірте мережу: чи є вихідний IP residential або data-center, чи відповідає інформація про оператора належності IP і чи не розкриває WebRTC адресу, що не узгоджується з середовищем. Наприкінці перевірте поведінкові можливості: touch events, показники сенсорів і набір шрифтів мають виглядати як у мобільного пристрою.
Якщо кілька пунктів не збігаються, спочатку знайдіть параметр, що суперечить загальній картині, а не створюйте середовище заново багато разів. Повторне створення не усуває внутрішніх суперечностей між параметрами.
Є ще один важливий момент: аномалія на сторонній сторінці перевірки не обов'язково означає проблему самого середовища. Різні сайти збирають дані по-різному; одні запускають скрипти й читають характеристики браузера, інші аналізують request headers, тому те саме середовище може мати різні результати на різних сайтах. Розширення браузера можуть змінювати інформацію, доступну сторінці, а застаріла IP-база може неправильно визначити розташування residential IP. Корисніше обрати один регулярно оновлюваний і надійний тестовий сайт як орієнтир, ніж постійно порівнювати багато сервісів.
Мобільна симуляція не замінює реальний пристрій
Для деяких сценаріїв усе ще потрібні фізичні пристрої: тести, що вимагають реальних даних сенсорів, камери або повної функціональності гіроскопа; етапи risk control, де платформа має дуже суворі вимоги до автентичності пристрою й перевіряє його всередині App; а також перевірки з реальними платежами чи реальною мережею оператора. Крім того, частина функцій платформи доступна лише в native-клієнті й відсутня у web, тому симульоване середовище їх не покриє.
Практичний розподіл такий: мобільні сценарії, які можна охопити через web, віддати симульованому середовищу, а перевірки на рівні hardware і App виконувати на реальних пристроях. Ці підходи доповнюють одне одного, а не замінюють.
Часті запитання
Чи достатньо змінити лише UA, щоб пройти перевірку Зазвичай ні. UA — один із найпростіших параметрів для окремої зміни й водночас один із найпростіших для перехресної перевірки. Якщо роздільна здатність, шрифти, мова, часовий пояс і touch-можливості не збігаються, невідповідність легко помітити.
Чи варто одному акаунту постійно залишатися на mobile або desktop Стабільність краща. Часте перемикання одного акаунта між двома класами пристроїв може саме по собі бути незвичним сигналом. Тип пристрою в середовищі має відповідати звичному способу використання акаунта.
Що враховувати з погляду compliance Використовуйте це лише для тестування власних акаунтів і процесів вашого бізнесу. Не використовуйте для підробки ідентичності пристрою з метою обходу перевірок платформи або для шахрайських дій.
Підсумок
Симуляція мобільного відбитка — це не зміна одного параметра, а узгодження всього набору з ідентичністю пристрою та цільовим ринком. Екран, модель, сенсори, мережа й UA мають бути правдоподібними окремо й не суперечити одне одному. Керуйте mobile і desktop середовищами окремо, тримайте один акаунт на стабільному профілі пристрою протягом тривалого часу й використовуйте окреме вихідне з'єднання, що відповідає регіону. Інструменти керування середовищами на кшталт PurpleMark можуть під час створення зв'язати параметри пристрою й системи, proxy та стартову сторінку, а при кожному запуску відновлювати ті самі налаштування, усуваючи потребу в повторній конфігурації.
