Налаштування політики конфіденційності на 1С-Бітрікс

Ми налаштовуємо політику конфіденційності на 1С-Бітрікс з урахуванням вимог 152-ФЗ «Про персональні дані» та GDPR. Пропуск згоди користувача — прямий шлях до штрафу до 500 000 рублів за російською практикою або до 4% річного обороту за європейським регламентом. На Бітрікс-сайтах дані збираються в кількох місцях: форми зворотного зв'язку, реєстрація, оформлення замовлення, підписка. Кожну точку потрібно оснастити чекбоксом і посиланням на політику. Без цього сайт вразливий до судових претензій та блокувань. Наша команда має 5+ років досвіду в розробці під Бітрікс і реалізувала понад 50 проектів з налаштування політик конфіденційності. Ми гарантуємо проходження перевірок Роскомнагляду при дотриманні всіх вимог.

Де збираються персональні дані на Бітрікс

Форми на Бітрікс використовують різні компоненти та таблиці. Розберемо всі основні точки збору та механізми збереження даних.

Кожну форму потрібно доопрацювати — додати чекбокс згоди та серверну валідацію. Без цього ви ризикуєте отримати припис від Роскомнагляду.

Як додати чекбокс згоди у форму зворотного зв'язку?

Розглянемо на прикладі компонента bitrix:main.feedback. У шаблоні додаємо поле:

<label class="agreement-label">
    <input type="checkbox" name="agree_personal_data" required>
    Я погоджуюся з
    <a href="/privacy-policy/" target="_blank">політикою конфіденційності</a>
</label>

Серверна валідація — у result_modifier.php компонента або обробнику події OnBeforeWebFormSend:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'form', 'OnBeforeWebFormSend',
    function(\Bitrix\Main\Event $event) {
        $fields = $event->getParameter('fields');
        if (empty($fields['agree_personal_data'])) {
            return new \Bitrix\Main\EventResult(
                \Bitrix\Main\EventResult::ERROR,
                'Необхідна згода на обробку персональних даних'
            );
        }
    }
);

Це мінімальний набір. Для всіх форм використовуйте аналогічний підхід.

Як налаштувати cookie-банер?

Для користувачів із ЄС актуальний GDPR — вимагає інформованої згоди на використання кукі. Бітрікс не надає вбудованого cookie-банера. Розглянемо варіанти:

Наш досвід показує: кастомний банер окупається на другому проекті. Ми використовуємо localStorage для зберігання згоди та блокуємо аналітичні теги до отримання згоди. Впровадження займає 1–2 дні. На практиці, блокування скриптів Google Analytics та Яндекс.Метрики до отримання згоди може знизити кількість зібраних даних на 20-30%, але це вимагається законом GDPR у Євросоюзі. Правильна реалізація банера запобігає штрафам від 10 до 100 млн. євро.

Чому важливо логувати згоди?

Факт отримання згоди — доказ вашої добросовісності. Роскомнагляд може запитати його в будь-який момент. Рекомендуємо створити таблицю bl_consent_log:

CREATE TABLE bl_consent_log (
    id         SERIAL PRIMARY KEY,
    user_id    INT,
    ip         VARCHAR(45),
    form_id    VARCHAR(100),
    consent_text_hash VARCHAR(64), -- хеш версії тексту політики
    created_at TIMESTAMP DEFAULT NOW()
);

При кожному форм-сабміті записуйте дані. Це убезпечить вас від претензій. На практиці судові спори часто вирішуються на вашу користь, якщо ви можете пред'явити лог згод з IP та часовою міткою. Версіонування політики через хеш дозволяє довести, що користувач погодився саме з тією версією тексту, яка була актуальна на момент згоди.

Процес налаштування під ключ

Ми виконуємо роботу поетапно:

1. Аудит — знайти всі точки збору персональних даних на сайті.
2. Проектування — вибрати спосіб додавання чекбоксів та cookie-банера.
3. Реалізація — додати чекбокси з валідацією, створити сторінку політики, налаштувати логування.
4. Тестування — перевірити всі форми, переконатися в коректному записі згод.
5. Деплой — викотити зміни на продакшн.

Наш підхід у 3 рази швидший за стандартний завдяки використанню шаблонних модулів та автоматизації перевірки. Якщо вам потрібне налаштування політики конфіденційності під ключ, замовте аудит сайту у наших інженерів. Отримайте консультацію з 152-ФЗ та GDPR вже сьогодні.

Що входить у налаштування

• Додавання чекбоксів згоди з серверною валідацією у всі форми сайту
• Створення сторінки політики конфіденційності
• Налаштування cookie-банера з підтримкою GTM
• Таблиця логування згод з прив'язкою до версії політики
• Перевірка повноти охоплення всіх точок збору персональних даних

Захист вашого бізнесу

Штрафи за порушення вимог персональних даних постійно зростають. На практиці, компанії, які пропустили згоди на обробку, отримували значні штрафи. Наша робота запобігає цим ризикам за допомогою повного охоплення всіх форм та правильного логування згод. Ми використовуємо перевірені підходи, які пройшли судові перевірки та відповідають вимогам наглядових органів. Після нашого налаштування ваш сайт повністю відповідає російському та європейському законодавству.

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

Інструменти для розробки парсерів

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

Отримайте консультацію: розкажіть про своє джерело даних — ми підберемо оптимальний підхід. Зв’яжіться для оцінки вашого проекту — запропонуємо рішення під ваш бюджет. Гарантуємо стабільну роботу парсерів і повну підтримку.