tradein/domclick: аудит полноты — что есть на странице карточки и чего мы не забираем #3252

New issue

Open

opened 2026-08-29 20:04:09 +00:00 by lekss361 · 0 comments

lekss361 commented

2026-08-29 20:04:09 +00:00

Owner

Зачем

Разбор 29.08 показал, что дефекты добора Домклика были не в парсинге, а в транспорте — но сам вопрос «а всё ли нужное мы вообще забираем со страницы» не проверялся ни разу. Сейчас список полей взят из формы SSR-стейта, подтверждённой на одной живой карточке 27.06 (productCard 2075729321), и с тех пор не сверялся.

Что забираем сейчас

Layer B (packages/scraper-kit/src/scraper_kit/providers/domclick/detail.py) кладёт в listings: repair_state / repair_type, living_area_m2, kitchen_area_m2, balconies_count, has_balcony, sale_type, owners_count, encumbrances_clean, year_built, views_total, плюс историю цен в offer_price_history.

В raw_payload (мерджем, не колонками): wall_type, floor_type, entrance_count, quarters_count, energy_efficiency, building_series, domclick_building_guid, egrn_area, demand (звонки / избранное / дубли), collateral, collateral_sber, balconies_raw, avm (оценка Домклика).

Что сделать

Взять 3-5 живых карточек разного типа (вторичка, новостройка, залоговая) и выгрузить __SSR_STATE__ целиком, обойдя дерево. Сравнить с тем, что читает парсер.
Отдельно проверить узлы, которые парсер трогает частично или по догадке:
- egrn_area — в коде прямо написано «точное написание ключа не подтверждено; пробуем несколько» (area / rosreestrArea / object_area). Выяснить настоящее имя.
- productCard.egrnData — какие ещё поля ЕГРН там лежат помимо owners_count / collateral.
- productCard.legalOptions — берём только saleType.
- pricePrediction (AVM) — сейчас складывается целиком в raw_payload.avm, не разобрана.
Решить по каждому неиспользуемому полю: нужно ли оно оценщику / витрине, и если да — колонка в listings или остаётся в raw_payload.
Проверить, не поехала ли форма стейта с 27.06 — если поехала, парсер молча отдаёт None (все поля None-safe, крэша не будет, будет тихая дыра).

Осторожно с интерпретацией заполненности

Считать долю заполненных полей по активным объявлениям нельзя — она врёт. Пример: living_area_m2 заполнена у 16 активных карточек из 3061, и это выглядит как сломанный парсер, но разбивка по дням показывает, что все свежие обогащения поле заполняют (10 из 10 за 29.08), а массовое обогащение 18.07 (6296 карточек) давно ушло в неактивные. Дыра там не в разборе, а в покрытии: деталей не видели 56 % активных карточек, потому что добор месяцами умирал на первых трёх.

Связано

#3250, #3244, #3246. Соседняя задача про дом — отдельным тикетом.

## Зачем Разбор 29.08 показал, что дефекты добора Домклика были не в парсинге, а в транспорте — но сам вопрос «а всё ли нужное мы вообще забираем со страницы» не проверялся ни разу. Сейчас список полей взят из формы SSR-стейта, подтверждённой на одной живой карточке 27.06 (`productCard` 2075729321), и с тех пор не сверялся. ## Что забираем сейчас Layer B (`packages/scraper-kit/src/scraper_kit/providers/domclick/detail.py`) кладёт в `listings`: `repair_state` / `repair_type`, `living_area_m2`, `kitchen_area_m2`, `balconies_count`, `has_balcony`, `sale_type`, `owners_count`, `encumbrances_clean`, `year_built`, `views_total`, плюс историю цен в `offer_price_history`. В `raw_payload` (мерджем, не колонками): `wall_type`, `floor_type`, `entrance_count`, `quarters_count`, `energy_efficiency`, `building_series`, `domclick_building_guid`, `egrn_area`, `demand` (звонки / избранное / дубли), `collateral`, `collateral_sber`, `balconies_raw`, `avm` (оценка Домклика). ## Что сделать 1. Взять 3-5 живых карточек разного типа (вторичка, новостройка, залоговая) и **выгрузить `__SSR_STATE__` целиком**, обойдя дерево. Сравнить с тем, что читает парсер. 2. Отдельно проверить узлы, которые парсер трогает частично или по догадке: - `egrn_area` — в коде прямо написано «точное написание ключа не подтверждено; пробуем несколько» (`area` / `rosreestrArea` / `object_area`). Выяснить настоящее имя. - `productCard.egrnData` — какие ещё поля ЕГРН там лежат помимо `owners_count` / `collateral`. - `productCard.legalOptions` — берём только `saleType`. - `pricePrediction` (AVM) — сейчас складывается целиком в `raw_payload.avm`, не разобрана. 3. Решить по каждому неиспользуемому полю: нужно ли оно оценщику / витрине, и если да — колонка в `listings` или остаётся в `raw_payload`. 4. Проверить, не поехала ли форма стейта с 27.06 — если поехала, парсер молча отдаёт `None` (все поля None-safe, крэша не будет, будет тихая дыра). ## Осторожно с интерпретацией заполненности Считать долю заполненных полей по активным объявлениям **нельзя** — она врёт. Пример: `living_area_m2` заполнена у 16 активных карточек из 3061, и это выглядит как сломанный парсер, но разбивка по дням показывает, что все свежие обогащения поле заполняют (10 из 10 за 29.08), а массовое обогащение 18.07 (6296 карточек) давно ушло в неактивные. Дыра там не в разборе, а в покрытии: деталей не видели 56 % активных карточек, потому что добор месяцами умирал на первых трёх. ## Связано #3250, #3244, #3246. Соседняя задача про дом — отдельным тикетом.