lekss361/gendesign

Fork 0

Авито: измерить потолок карточек на сессию и развести «аккаунт vs прогретые куки» #3181

New issue

Open

opened 2026-08-28 16:57:52 +00:00 by bot-backend · 2 comments

bot-backend commented

2026-08-28 16:57:52 +00:00

Collaborator

Sub-issue #3177, измерение — можно параллельно с остальными, результат нужен до раскатки темпа.

Два незакрытых вопроса

1. Сколько карточек держит одна сессия. Замер 28.08 дал 5/5 при паузе 1,5 с и остановился на пяти — это не потолок. От числа зависит, сколько учёток нужно и с каким темпом их пускать. Мерить до первого блока, с шагом, фиксируя номер карточки.

2. Что именно работает — учётная запись или прогретый набор кук. Разница дорогая: куки не рискуют баном аккаунта, а бан аккаунта необратим дороже бана адреса (восстановление через телефон). Разделяется прогоном с тем же набором кук, но без авторизационной: пройдёт — значит достаточно прогрева и авторизация не нужна вовсе.

Если хватит кук — весь риск персонифицированного сбора снимается, и sub-issue про учётки схлопывается до «прогрев + липкость».

Приёмка

Известно число карточек до первого блока (медиана по 3+ попыткам)
Известно, проходит ли прогретая неавторизованная сессия
Результат записан в вольт и в #3177; темп в воркере выставлен от измеренного числа

Оценка S. Refs #3177

Sub-issue #3177, **измерение** — можно параллельно с остальными, результат нужен до раскатки темпа. ## Два незакрытых вопроса **1. Сколько карточек держит одна сессия.** Замер 28.08 дал 5/5 при паузе 1,5 с и остановился на пяти — это не потолок. От числа зависит, сколько учёток нужно и с каким темпом их пускать. Мерить до первого блока, с шагом, фиксируя номер карточки. **2. Что именно работает — учётная запись или прогретый набор кук.** Разница дорогая: **куки не рискуют баном аккаунта**, а бан аккаунта необратим дороже бана адреса (восстановление через телефон). Разделяется прогоном с тем же набором кук, но без авторизационной: пройдёт — значит достаточно прогрева и авторизация не нужна вовсе. Если хватит кук — весь риск персонифицированного сбора снимается, и sub-issue про учётки схлопывается до «прогрев + липкость». ## Приёмка - [ ] Известно число карточек до первого блока (медиана по 3+ попыткам) - [ ] Известно, проходит ли прогретая **неавторизованная** сессия - [ ] Результат записан в вольт и в #3177; темп в воркере выставлен от измеренного числа Оценка S. Refs #3177

bot-backend added the

labels 2026-08-28 16:57:52 +00:00

bot-backend referenced this issue

2026-08-28 16:57:52 +00:00

Авито detail: авторизованные сессии — хранение кук, липкость к прокси, прогрев в браузерном пути #3177

bot-backend commented

2026-08-28 17:03:12 +00:00

Author

Collaborator

Обязательное условие замера: мерить в том браузере, которым ходит прод, а не в обычном Chrome.

Уточняю происхождение цифры 5/5 из #3177, потому что оно ограничивает её применимость. Замер делался через CDP к живому Chrome, и запросы шли изнутри уже открытой вкладки Авито — in-page fetch() с credentials: 'include'. Curl не участвовал.

Такой запрос наследует от страницы всё сразу: полный набор кук (включая HttpOnly), TLS-отпечаток настоящего Chrome, полный набор заголовков, живой referer, историю навигации. Это самое благоприятное условие из возможных.

Прод так не ходит: camoufox в сайдкаре, свой отпечаток, холодный старт.

Поэтому:

5/5 — верхняя граница, а не переносимое число. Замер доказывает, что карточка отдаётся при правильной сессии и что дело не в темпе. Он не доказывает, что столько же выйдет из сайдкара с теми же куками.
Мерить потолок в обычном Chrome — значит намерить условие, которое скраппер не воспроизведёт, и выставить темп по завышенной цифре.

Дополнение к приёмке

Замер проведён в браузере сайдкара (camoufox), с подгруженными куками — не в десктопном Chrome
Если числа сайдкара и Chrome расходятся — зафиксировать обе, темп выставлять по сайдкару
Разница «аккаунт vs прогретые куки» проверяется тоже в сайдкаре

**Обязательное условие замера: мерить в том браузере, которым ходит прод, а не в обычном Chrome.** Уточняю происхождение цифры 5/5 из #3177, потому что оно ограничивает её применимость. Замер делался через CDP к живому Chrome, и запросы шли **изнутри уже открытой вкладки Авито** — in-page `fetch()` с `credentials: 'include'`. Curl не участвовал. Такой запрос наследует от страницы всё сразу: полный набор кук (включая `HttpOnly`), TLS-отпечаток настоящего Chrome, полный набор заголовков, живой referer, историю навигации. Это **самое благоприятное условие из возможных**. Прод так не ходит: camoufox в сайдкаре, свой отпечаток, холодный старт. Поэтому: - **5/5 — верхняя граница, а не переносимое число.** Замер доказывает, что карточка отдаётся при правильной сессии и что дело не в темпе. Он **не** доказывает, что столько же выйдет из сайдкара с теми же куками. - Мерить потолок в обычном Chrome — значит намерить условие, которое скраппер не воспроизведёт, и выставить темп по завышенной цифре. ## Дополнение к приёмке - [ ] Замер проведён **в браузере сайдкара** (camoufox), с подгруженными куками — не в десктопном Chrome - [ ] Если числа сайдкара и Chrome расходятся — зафиксировать обе, темп выставлять по сайдкару - [ ] Разница «аккаунт vs прогретые куки» проверяется тоже в сайдкаре

bot-backend commented

2026-08-28 17:34:38 +00:00

Author

Collaborator

Замер проведён прямо в сайдкаре прода (28.08, ~17:10 UTC). Результат не тот, которого я ждал, и часть моих предыдущих выводов он ослабляет.

16 карточек, ожидающих обогащения, через POST /fetch живого tradein-browser. Чередование режимов, чтобы дрейф состояния пула бил по обеим группам одинаково. Дискриминатор — размер: заглушка ~6 КБ против живой карточки 550-900 КБ.

холодный goto (как ходит прод)   7/8 прошло
origin = SERP Авито              8/8 прошло

Разницы между режимами на этой выборке нет. Единственный провал в холодной группе — HTTP 500 самого сайдкара, а не блок площадки.

Что замер всё-таки установил твёрдо

Аккаунт для этих карточек сейчас не нужен. 15 из 16 анонимных запросов, без единой куки и без авторизации, вернули полные карточки. При нынешнем состоянии пула авторизация ничего не решает.

Что он опроверг

Первый заход (n=1) выглядел решающе: карточка 8270330752 холодным заходом дала 5 918 байт — заглушку, — а с origin те же 712 239 байт живой карточки. Я успел назвать это решающим.

Через несколько минут та же карточка тем же холодным режимом отдалась целиком (663 886 байт).

Отсюда главное следствие: блок стохастичен, а не детерминирован по карточке. Сравнения на малых выборках — включая мои собственные 5/5 из #3177 — доказывают меньше, чем кажется. Пять успехов подряд при вероятности успеха ~0.7 случаются в каждом шестом заходе.

Новая находка: порог обрыва принимает случайную серию за бан

Прогон 5200 завершился так:

enriched=43  attempted=63  blocked=20  status=banned

68% успеха — и всё равно banned, потому что где-то сошлись 5 блоков подряд.

При доле блоков 0.32 пять подряд в одной позиции — вероятность 0.0034, но позиций в прогоне около шестидесяти. Итого примерно каждый пятый совершенно здоровый прогон обрывается случайной серией и рапортует «IP rate-limited».

Для выгоревшего пула правило верное: прогоны 5140-5190 давали 5 блоков из 5 попыток, там серия — не случайность. Для здорового — ложная тревога, которая к тому же выбрасывает остаток очереди.

Правило должно смотреть на долю блоков в окне, а не на длину серии. Завожу отдельным тикетом.

Следствие для плана #3177

Различающий эксперимент «аккаунт против прогретых кук» сейчас поставить нельзя: пул здоров, анонимный холодный заход и так даёт 94%, и все режимы неразличимы. Мерить надо на выгоревшем пуле — то есть либо ждать деградации, либо воспроизводить её намеренно.

Практический вывод: не строить машинерию аккаунтов на нынешних данных. Сначала честный порог обрыва (он даёт выигрыш немедленно и без риска), потом замер под нагрузкой, и только потом решение про сессии.

**Замер проведён прямо в сайдкаре прода (28.08, ~17:10 UTC). Результат не тот, которого я ждал, и часть моих предыдущих выводов он ослабляет.** 16 карточек, ожидающих обогащения, через `POST /fetch` живого `tradein-browser`. Чередование режимов, чтобы дрейф состояния пула бил по обеим группам одинаково. Дискриминатор — размер: заглушка ~6 КБ против живой карточки 550-900 КБ. ``` холодный goto (как ходит прод) 7/8 прошло origin = SERP Авито 8/8 прошло ``` **Разницы между режимами на этой выборке нет.** Единственный провал в холодной группе — HTTP 500 самого сайдкара, а не блок площадки. ## Что замер всё-таки установил твёрдо **Аккаунт для этих карточек сейчас не нужен.** 15 из 16 анонимных запросов, без единой куки и без авторизации, вернули полные карточки. При нынешнем состоянии пула авторизация ничего не решает. ## Что он опроверг Первый заход (n=1) выглядел решающе: карточка `8270330752` холодным заходом дала 5 918 байт — заглушку, — а с `origin` те же 712 239 байт живой карточки. Я успел назвать это решающим. Через несколько минут **та же карточка тем же холодным режимом отдалась целиком** (663 886 байт). Отсюда главное следствие: **блок стохастичен, а не детерминирован по карточке**. Сравнения на малых выборках — включая мои собственные 5/5 из #3177 — доказывают меньше, чем кажется. Пять успехов подряд при вероятности успеха ~0.7 случаются в каждом шестом заходе. ## Новая находка: порог обрыва принимает случайную серию за бан Прогон 5200 завершился так: ``` enriched=43 attempted=63 blocked=20 status=banned ``` 68% успеха — и всё равно `banned`, потому что где-то сошлись 5 блоков подряд. При доле блоков 0.32 пять подряд в одной позиции — вероятность 0.0034, но позиций в прогоне около шестидесяти. Итого **примерно каждый пятый совершенно здоровый прогон обрывается случайной серией** и рапортует «IP rate-limited». Для выгоревшего пула правило верное: прогоны 5140-5190 давали 5 блоков из 5 попыток, там серия — не случайность. Для здорового — ложная тревога, которая к тому же выбрасывает остаток очереди. Правило должно смотреть на **долю блоков в окне**, а не на длину серии. Завожу отдельным тикетом. ## Следствие для плана #3177 Различающий эксперимент «аккаунт против прогретых кук» **сейчас поставить нельзя**: пул здоров, анонимный холодный заход и так даёт 94%, и все режимы неразличимы. Мерить надо на выгоревшем пуле — то есть либо ждать деградации, либо воспроизводить её намеренно. Практический вывод: **не строить машинерию аккаунтов на нынешних данных**. Сначала честный порог обрыва (он даёт выигрыш немедленно и без риска), потом замер под нагрузкой, и только потом решение про сессии.

bot-backend referenced this issue

2026-08-28 17:34:39 +00:00

Обрыв по серии блоков срабатывает на КАЖДОМ прогоне (40 из 40 за 14 дней) — критерий не несёт информации #3184