Мониторинг цен в ecommerce: браузерный слой
Разделите мониторинг цен на планирование, браузер и обнаружение изменений, зафиксировав локаль, валюту, регион и момент рендеринга, чтобы у разницы цен была одна причина
BotBrowser Team
Нужна структурированная документация по теме Сеть?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Браузер для мониторинга цен в ecommerce является одним этапом конвейера, а не самим конвейером. Записанная цена может отличаться от цены предыдущего запуска потому, что страница отрендерилась в другой валюте, потому что чтение произошло до того, как элемент цены стабилизировался, потому что маршрут выходил из другого региона, или потому что продавец действительно изменил число. Только четвёртая причина является фактом данных; остальные три представляют собой дефекты измерения, которые браузерный слой либо предотвращает, либо незаметно вносит, включая случай, когда маршрут выходит из региона, который оператор не планировал. BotBrowser предоставляет настраиваемую среду Chromium, которая запускается из конфигурации, заданной оператором, и возвращает отрендеренную страницу, поэтому браузерный этап можно удерживать неизменным, пока измеряются другие этапы. Он не может планировать задания, не хранит историю, не вычисляет различия, не решает, разрешает ли продавец сбор данных, и не гарантирует, какую цену покажет страница. Процедура предполагает принадлежащий оператору тестовый стенд или явно авторизованную цель и не содержит методов обхода защитных механизмов продавца.
TL;DR
- Конвейер описывается четырьмя этапами с одним владельцем у каждого: планирование, браузерный рендеринг, извлечение и обнаружение изменений. Разницу цен можно атрибутировать только тогда, когда границы этапов записаны для каждого наблюдения.
- До сравнения запусков фиксируются три видимых браузеру входа:
Accept-Languageвместе сnavigator.languages, валюта форматирования и регион выхода. Состояние cookie и сохранённых предпочтений на первом наблюдении тоже очищается или фиксируется, поскольку сохранённое предпочтение может переопределить все три. Изменение любого из них даёт другое отрендеренное число для одного и того же товара. - Вместо «ожидания цены» задаётся именованное условие готовности, например непустой узел цены, текст которого разбирается как число, а окружающий блок предложения завершён. Фиксированная пауза не является условием готовности.
- Денежные значения хранятся целыми в минорных единицах, а рядом указывается код валюты ISO 4217.
19.99как число с плавающей точкой теряет границу цента, от которой зависит сравнение, а¥1,980не является той же величиной, что$19.80. - Каждое наблюдение классифицируется как одно из четырёх: цена наблюдалась, цена отсутствует, запрос отклонён или страница не стабилизировалась. Сведение этих четырёх состояний в «цены нет» представляет собой дефект, из-за которого конвейер мониторинга выглядит точным, не будучи им.
Содержание
- Разложите нагрузку на четыре этапа
- Зафиксируйте переменные на стороне браузера
- Определите момент готовности и устаревшие чтения
- Отделите ошибку браузера от ошибки данных
- Практический вывод
Разложите нагрузку на четыре этапа
Задание мониторинга цен отвечает на один вопрос для каждого товара в каждом запуске: какое число показала эта страница в этот момент, в этой валюте, из этого региона? Всё остальное в конвейере существует, чтобы сделать этот ответ сопоставимым с предыдущим. Разделение работы на этапы делает различие объяснимым, потому что каждый этап может отказать способом, недоступным остальным.
| Этап | Чем владеет | Какой сбой может породить | Что не может исправить |
|---|---|---|---|
| Планирование | Какой товар, как часто, какой слот, бюджет повторов | Пропущенный слот, пересекающиеся запуски, дублирующиеся наблюдения | Неверное или устаревшее чтение |
| Браузерный рендеринг | Локаль, валюта, регион выхода, условие готовности | Чтение в неверной валюте, цена неверного региона, устаревшее чтение | Изменившуюся цену |
| Извлечение | Какой узел, какой парсер, какой запасной вариант | Ошибка разбора, ошибка единицы, неверное поле | Страницу, которая так и не стабилизировалась |
| Обнаружение изменений | Базовая линия, допуск, правило оповещения | Ложное оповещение, пропущенное оповещение, дрейф | Плохое наблюдение |
Таблица служит диагностическим инструментом, а не организационной схемой. Когда появляется различие, первый вопрос: какой этап породил два наблюдения, поскольку различие, вычисленное по двум разным конфигурациям браузера, не является изменением цены. Конвейер мониторинга, сообщающий «цена изменилась» без записи валюты, региона и условия готовности обоих наблюдений, выдаёт непроверяемое утверждение.
Зачем фиксировать границу этапа для каждого наблюдения
Хранить конфигурацию один раз на задание недостаточно. Задание, которое меняет настройку валюты посреди пакета или переключается на маршрут в другом регионе после ошибки прокси, порождает наблюдения, несопоставимые между собой, хотя идентификатор задания один и тот же. Эффективная конфигурация записывается рядом с каждым наблюдением, а не рядом с запуском.
Поля, которые стоит записывать для каждого наблюдения, невелики и стабильны: идентификатор сборки браузера, идентификатор профиля, эффективный Accept-Language, код валюты, использованный при извлечении, регион выхода по отчёту маршрута, имя условия готовности, отметка времени чтения и HTTP-статус ответа документа. С этими восемью полями два наблюдения можно сравнить или явно объявить несопоставимыми. Без них различие остаётся мнением.
Что браузерный этап может и не может сообщить
Браузер может сообщить то, что он отрендерил: текстовое содержимое узла, присутствующие на нём атрибуты, HTTP-статус документа, заголовки ответа, отправленные сервером, и момент, когда выбранное условие готовности стало истинным. Он также может сообщить тайминги запроса документа и его подресурсов.
Браузер не может сообщить, почему число именно таково. Он не скажет, означает ли 1,299 1,299 единиц валюты отображения или округлённую региональную цену, применил ли продавец скидку участника к другому аккаунту и закончилась ли акция между двумя запусками. Он также не сообщит, показала бы другую цену страница, которая так и не была получена. Это вопросы извлечения и бизнес-логики, и отнесение их к браузерному этапу приводит к неверному исправлению: команды, трактующие любое различие цен как проблему браузера, начинают менять профили, когда настоящей причиной была валюта по умолчанию.
Один товар, одна единица сравнения
До написания кода конвейера определяется, что считается одним и тем же товаром между запусками. Идентификаторы товара продавца нестабильны между регионами: один и тот же предмет может иметь разные идентификаторы для разных витрин, а региональный каталог может содержать вариант, которого нет в глобальном каталоге. В качестве единицы сравнения используется стабильный ключ на стороне оператора, а идентификатор продавца хранится рядом с ним как атрибут.
Если ключ на стороне оператора строится из URL, его сначала нормализуют: удаляют параметры отслеживания, приводят регистр пути к тому, который использует витрина, и отбрасывают фрагменты сессии. Два URL, различающиеся только параметром кампании, указывают на один товар, а трактовка их как двух товаров удваивает число наблюдений, не добавляя информации.
Зафиксируйте переменные на стороне браузера
Четыре поверхности на пути запроса меняют число, которое показывает страница, хотя у продавца ничего не изменилось. Три задаются внутри браузера: язык, который согласует страница, валюта, которую выбирает витрина, и состояние предпочтений или cookie, сохраняющееся между запросами. Четвёртая представляет собой регион выхода маршрута, который принадлежит слою маршрутизации и наблюдается только со стороны маршрута, но не со страницы. Они независимы, и каждый имеет собственный режим отказа.
Согласование языка и цепочка его разрешения
Витрина обычно выбирает язык из Accept-Language в запросе документа, из сегмента пути URL или поддомена, из cookie либо сохранённой настройки, либо из региона выхода, в порядке, который выбирает сайт. Внутри страницы navigator.language и navigator.languages описывают то, что сообщает браузер, а форматирование Intl разрешается относительно тега локали.
Это четыре отдельные поверхности, и они могут расходиться. Запрос с Accept-Language: de-DE, тогда как navigator.languages сообщает en-US, может дать немецкую страницу, клиентское форматирование которой всё равно выводит число в английском формате. Наблюдаемый результат таков: страница выглядит локализованной, но форматирует деньги иначе; именно такое смешанное состояние порождает фантомное различие цен.
| Поверхность | Кем задаётся | Откуда наблюдаема | Типичный дефект при расхождении |
|---|---|---|---|
Заголовок запроса Accept-Language | Параметрами контекста библиотеки автоматизации | Захваченными заголовками запроса | Сервер выбирает другой язык витрины |
navigator.language / navigator.languages | Профилем браузера | page.evaluate на странице | Меняется клиентский вывод Intl |
| Путь URL или поддомен | Запрошенным адресом | Итоговым URL | Запросы попадают на другую витрину |
| Сохранённая настройка или cookie | Предыдущей навигацией или потоком согласия | Cookie документа, хранилищем | Первый и последующие запросы расходятся |
Практическое правило состоит в том, чтобы свести все четыре поверхности к одному набору значений и проверить согласованность при первом наблюдении запуска. Playwright предоставляет параметры контекста для локали и часового пояса, поэтому заголовок и значения navigator можно согласовать в одном запуске, а page.evaluate позволяет прочитать то, что страница действительно видит, до любого извлечения.
Выбор валюты и форматирование
Валюта является частой причиной скрытых ошибок в конвейере мониторинга, потому что элемент цены обычно содержит отформатированную строку, а не машиночитаемое число. $1,299, 1.299 €, ¥1,299 и 1 299,00 € могут обозначать разные величины или одну и ту же величину в разных соглашениях. Отделить символ от цифр недостаточно: один и тот же глиф используют несколько валют.
В хранимых записях используются коды ISO 4217, а не символы. USD, EUR, GBP, JPY и CNY однозначны; $ неоднозначен, а ¥ применяется и для JPY, и для CNY. Если страница предоставляет машиночитаемую валюту, предпочтение отдаётся ей: Offer из schema.org содержит priceCurrency и price, а блок JSON-LD разбирать надёжнее, чем отрендеренную метку.
Минорные единицы важны по той же причине. Большинство валют используют два десятичных знака, но JPY и KRW используют ноль, а KWD и BHD три. Конвейер, умножающий каждую разобранную цену на 100 для получения целого значения в центах, масштабирует валюту без десятичных знаков на два порядка неверно. Хранятся код ISO 4217, показатель минорной единицы для этого кода и целая сумма; отображение форматируется из этих трёх полей.
Записывается и поведение округления. Intl.NumberFormat со стилем валюты округляет до числа дробных знаков по умолчанию для валюты, если не задано иное, поэтому страница, показывающая 1.995 как 2.00, уже отбросила информацию до того, как её увидело извлечение. Если для сравнения нужен третий знак, извлечение должно читать неформатированное значение или принять, что конвейер сравнивает округлённые цены.
Регион определяется маршрутом, а не браузером
Регион является входом, который команды чаще всего считают контролируемым, хотя это не так. Браузер может сообщить часовой пояс и набор тегов локали, а профиль может объявить геолокацию, но витрина определяет свой региональный каталог по тому, что может наблюдать в запросе, а это в первую очередь адрес выхода. Профиль, заявляющий один регион, тогда как маршрут выходит из другого, даёт страницу, чей региональный каталог и клиентское форматирование расходятся.
Согласовывать их нужно намеренно. Если нагрузке нужна немецкая витрина, маршрут должен выходить с немецкого адреса, Accept-Language должен нести немецкий, локаль контекста должна быть немецким тегом, а часовой пояс тем, который увидел бы немецкий посетитель. Согласование является свойством конфигурации запуска и проверяемо: итоговый URL, заголовок Content-Language документа, где он присутствует, и отрендеренная валюта вместе показывают, какая витрина ответила.
| Проверка | Что доказывает | Где читать |
|---|---|---|
| Итоговый URL после перенаправлений | Какой путь витрины ответил | page.url() |
Заголовок ответа Content-Language | Какой язык выбрал сервер | Захваченный ответ документа |
| Отрендеренный код валюты | Из какого каталога взята страница | Offer.priceCurrency или узел цены |
Intl.DateTimeFormat().resolvedOptions().timeZone | Какой часовой пояс видит страница | page.evaluate |
| Регион выхода маршрута | Из какого региона пришёл запрос | Отчёт самого маршрута, а не страницы |
Последняя строка не читается со страницы, поэтому её должен записывать слой, владеющий маршрутом. Страница может рендериться безупречно, пока маршрут выходит туда, куда оператор не собирался, и ничто в DOM этого не выявляет. Запись, которая должна сопровождать цену, и схема «один контекст на продавца и регион» разобраны в статье защита отпечатков для мониторинга ecommerce; фиксация региона, языка и маршрута на окно сравнения разобрана в статье профили браузера для SEO-мониторинга.
Запись зафиксированной конфигурации
Зафиксированные значения помещаются в одну запись, которую могут читать и этап извлечения, и этап обнаружения изменений. Рабочая форма представляет собой небольшой объект с тегами языка, кодом валюты и показателем минорной единицы, регионом, часовым поясом, именем условия готовности, идентификаторами браузера и профиля. Запись следует вместе с наблюдением.
Действуют два ограничения. Во-первых, запись описывает эффективную конфигурацию, а не запрошенную; при запросе de-DE, перенаправленном сайтом на английскую витрину, нужно записать то, что фактически ответило. Во-вторых, изменение конфигурации является событием конвейера, а не рутинной правкой: если настройка валюты меняется, наблюдения по обе стороны изменения несопоставимы, и этап обнаружения изменений должен об этом знать, а не получать готовое различие.
Определите момент готовности и устаревшие чтения
Узлы цен часто присутствуют раньше, чем становятся правильными. Серверный заполнитель, скелетон-элемент, этап клиентской гидратации и промо-баннер, переписывающий отображаемое число, могут появляться последовательно в рамках одной загрузки страницы. Чтение в неверный момент даёт число, которое действительно было на странице и никогда не было ценой.
Условие готовности вместо ожидания
Условие готовности записывается как предикат над страницей, а не как истёкшее время. Полезный предикат состоит из трёх частей: узел цены существует, его текст разбирается как число по объявленным правилам валюты, а структурный свидетель подтверждает полноту окружающего блока предложения, например, значение priceCurrency, маркер наличия или доступности либо включённый элемент добавления в корзину.
Третья часть отличает настоящее чтение от удачного. Страница может показать узел цены с числовой строкой задолго до сборки блока предложения, и предикат, проверяющий только узел, пройдёт на частичном рендере. Ожидание полного набора свидетелей стоит немного задержки и устраняет целый класс устаревших чтений.
Playwright предоставляет для этого примитивы напрямую: page.waitForFunction вычисляет предикат в странице, page.waitForSelector ограничивает ожидание присутствием узла, а page.waitForResponse ограничивает его конкретным ответом API, когда цена приходит по сети, а не в документе. Выбор между ними является решением о том, откуда берётся цена, и оно принадлежит записи запуска, потому что меняет смысл слова «готово».
| Источник цены | Примитив готовности | Что доказывает | Остаточный риск |
|---|---|---|---|
| Документ, отрендеренный сервером | waitForSelector по узлу цены плюс свидетель | Документ содержал предложение | Более поздний скрипт переписывает число |
| Узел после клиентской гидратации | waitForFunction по полному предикату | Клиент завершил сборку предложения | Последующий промо-скрипт меняет его |
| Цена, доставленная вызовом API | waitForResponse, совпадающий с эндпоинтом | Ответ с ценой пришёл | DOM ещё не обновлён |
| Цена за взаимодействием | Скриптовое взаимодействие, затем предикат | Взаимодействие завершилось | Взаимодействие было не тем |
Четвёртая строка является местом, где конвейер мониторинга может тихо нарушить собственную границу: взаимодействие, раскрывающее цену участника или региональную цену, является аутентифицированным или персонализированным состоянием, и нагрузка, авторизованная только для публичных страниц, должна классифицировать такое наблюдение как выходящее за рамки, а не извлекать его.
Устаревшие чтения, отсутствующие цены и отклонённые запросы
Эти три исхода выглядят одинаково для конвейера, хранящего только число или null, но требуют разных ответов. Устаревшее чтение означает, что условие готовности было неверным, и наблюдение нужно отбросить, а не сохранять. Отсутствующая цена означает, что страница полностью отрендерена, а блок предложения не содержал цены; это реальная находка о товаре. Отклонённый запрос означает, что браузер так и не получил страницу; это вопрос доступа, а не данных.
Классификация выполняется явно. С каждым наблюдением хранится код исхода: observed, absent, refused или unsettled. Ниже по потоку только наблюдения observed питают различие цен, absent питает сигнал об изменении каталога, refused питает журнал доступа, а unsettled питает счётчик дефектов условия готовности. Конвейер, трактующий все четыре как «цены нет», будет сообщать о стабильном каталоге, систематически не читая его.
Условные запросы и смысл 304
Когда нагрузка перечитывает уже виденную страницу, сервер может ответить 304 Not Modified на условный запрос с If-None-Match и предыдущим ETag либо с If-Modified-Since и предыдущим Last-Modified. 304 не является сбоем и не является свежим наблюдением: он означает, что представление, которое сервер отправил бы, не изменилось относительно описанного валидатором.
Для мониторинга цен 304 одновременно полезное свидетельство и ловушка. Полезное потому, что подтверждает, что документ не менялся с момента выдачи валидатора. Ловушка потому, что валидатор описывает документ, а не цену: цена, получаемая отдельным вызовом API и внедряемая на клиенте, может измениться, пока ETag документа остаётся тем же. Если цена приходит по сети, условие нужно ставить по валидатору того ответа, а не документа.
Vary усложняет тот же вопрос. Ответ с Vary: Accept-Language означает, что кэшированное представление ключуется этим заголовком, поэтому запуск, меняющий настройку языка, не перечитывает ту же запись кэша. Запись заголовка Vary рядом с наблюдением не позволяет последующему анализу предположить, что два наблюдения имели общий ключ кэша, когда это не так.
Часы, отметка времени и порядок
Время наблюдения хранится по одним часам, а собственный временной сигнал сервера рядом с ним, когда ответ его предоставляет, например заголовок Date. Date.now() страницы и часы хоста могут расходиться, и конвейер, смешивающий их, порождает наблюдения, порядок которых недостоверен.
Порядок здесь важнее точности. Если два наблюдения одного товара сохранены со временем, инвертирующим их фактический порядок, этап обнаружения изменений сообщит об изменении цены в неверном направлении и, возможно, оповестит о нём. Монотонно возрастающий номер последовательности на запуск, в дополнение к настенному времени, делает порядок восстановимым даже при совпадении двух отметок.
Отделите ошибку браузера от ошибки данных
Ценность разделения на четыре этапа в том, что оно превращает «цена выглядит неверной» в конкретное проверяемое утверждение. Границы этапов используются как первый шаг классификации, а коды исхода наблюдения как второй.
Матрица атрибуции сбоев
| Симптом | Наиболее вероятный этап | Первая проверка | Чего не делать |
|---|---|---|---|
| Все товары региона показывают другую валюту | Браузерный рендеринг | Эффективная валюта и регион выхода в записи запуска | Менять профили |
| Цена одного товара меняется и возвращается | Обнаружение изменений | Допуск и правило оповещения | Переписывать экстрактор |
| Цены отсутствуют у части товаров | Извлечение | Есть ли цена в блоке предложения вообще | Повторять с новым профилем |
| В запуске есть пробелы через равные интервалы | Планирование | Пересечение слотов и бюджет повторов | Увеличивать параллелизм |
| Цены стабильно отстают на один шаг | Браузерный рендеринг | Условие готовности и число устаревших чтений | Винить продавца |
| Цена отличается в 100 раз | Извлечение | Показатель минорной единицы для кода валюты | Подстраивать правило оповещения |
Столбец «Чего не делать» передаёт операционный смысл таблицы. У каждого из этих симптомов есть заманчивое исправление, затрагивающее другой этап, и его применение превращает диагностируемый дефект в постоянное необъяснимое смещение.
Запись запуска, поддерживающая классификацию
Запись должна быть достаточно малой, чтобы её действительно писали, и достаточно полной, чтобы применить матрицу выше без повторного запуска. Рабочая форма на одно наблюдение несёт ключ товара, время наблюдения и номер последовательности, код исхода, исходный текст цены, разобранную целую сумму, код ISO 4217 и показатель минорной единицы, эффективные язык и регион, имя условия готовности, HTTP-статус документа и итоговый URL.
Два производных поля делают матрицу применимой в масштабе: число устаревших чтений на запуск и число сбоев по этапам. Первое обозначает количество наблюдений, чей предикат прошёл, но набор свидетелей был неполным; после настройки оно должно быть нулевым. Второе группирует коды исхода по этапам, так что растущий счётчик refused видимо является проблемой доступа, а растущий unsettled проблемой готовности.
Контрольный список перед запуском
- Единица сравнения является ключом товара на стороне оператора, а идентификатор продавца хранится как атрибут.
- Поверхности языка согласованы: заголовок запроса,
navigator.languages, путь URL и любая сохранённая настройка. - Валюта хранится как код ISO 4217 с показателем минорной единицы, а не как символ.
- Регион выхода записан слоем маршрута и соответствует предполагаемой витрине.
- Условие готовности является именованным предикатом с набором свидетелей, а не фиксированная пауза.
- Каждое наблюдение несёт код исхода из
observed,absent,refused,unsettled. - Валидаторы условных запросов привязаны к ответу, который действительно несёт цену.
- Допуск обнаружения изменений объявлен до первого оповещения, а не после первого ложного.
- Изменение конфигурации записано как событие, разделяющее сопоставимые окна наблюдений.
FAQ
Определяет ли браузер цену, которую показывает страница?
Нет. Цену определяет витрина по собственному каталогу, акциям, состоянию аккаунта и региональным правилам. Браузерный слой управляет тем, что витрина может наблюдать в запросе, и это наблюдение может влиять на то, какой каталог или валюта будут отданы, но само число приходит из систем продавца. Трактовка браузера как причины различия цен ведёт к беспорядочным изменениям конфигурации, которые так и не затрагивают настоящую переменную.
Помогает ли более длительное ожидание при устаревших чтениях?
Оно уменьшает симптом, не устраняя причину. Более длинная фиксированная пауза снижает вероятность чтения частичного рендера, но также снижает пропускную способность и всё равно отказывает, когда страница медленнее выбранной задержки. Предикат готовности, называющий узел цены и набор свидетелей, отказывает видимо и конкретно, что и нужно конвейеру мониторинга: наблюдение «не стабилизировалось» пригодно, а наблюдение, молча захватившее заполнитель, непригодно.
Хранить цены как числа с плавающей точкой или как целые?
Как целые в минорных единицах, с кодом ISO 4217 и его показателем рядом с суммой. Двоичная плавающая точка не представляет большинство десятичных дробей точно, поэтому сохранённое 19.99 не равно ровно девятнадцати и девяноста девяти сотым, а повторяющаяся арифметика над такими значениями накапливает ошибку. Целые минорные единицы делают равенство и разность точными, а показатель не позволяет масштабировать валюту без десятичных знаков так, будто у неё есть центы.
Практический вывод
Начинать нужно с границы этапов, а не с конфигурации браузера. Четыре этапа выписываются, для каждого называется владелец, а фактически действовавшие параметры рендеринга прикрепляются к отдельной записи наблюдения, а не к заданию целиком. Затем пауза заменяется предикатом готовности, называющим и узел цены, и структурный свидетель, а каждое наблюдение классифицируется одним из четырёх кодов исхода: observed, absent, refused, unsettled.
Следующее действие невелико: взять один товар на авторизованной странице, записать его цену дважды при зафиксированной конфигурации и подтвердить, что оба наблюдения несут одинаковые код валюты, регион, условие готовности и код исхода. Если это так, конвейер сможет атрибутировать будущее различие. Если нет, различие уже присутствует, и браузерный слой является первым местом для проверки.
Sources
- Playwright: BrowserType.launch
- Playwright: Network
- Playwright: Browser contexts
- RFC 9110: HTTP Semantics
- RFC 9111: HTTP Caching
- Schema.org: Offer
- ISO 4217 currency codes
- ECMA-402: Intl.NumberFormat
- BotBrowser: Начало работы с Playwright
- BotBrowser: Согласование прокси и геолокации
- BotBrowser: Timezone, locale, and language
Эта статья входит в руководство: Обзор настройки прокси: карта сетевых решений браузера
Похожие статьи
Защита отпечатков для мониторинга цен в электронной коммерции
РазвертываниеПрофили браузера для SEO-мониторинга и отслеживания SERP
СетьСетевая согласованность браузера для защиты приватности
РазвертываниеСбор вакансий: границы браузера
СетьДинамическое переключение прокси для отдельных контекстов браузера
СетьTLS-сертификаты и доверие браузера к соединению
Выполните ту же проверку в BotBrowser
Загрузите профиль, сохраните внутри браузера те сигналы, о которых только что прочитали, и подтвердите результат на своей машине до раскатки.