😅 Спидран комбайна в Power BI. Ускорил, дополнил, доделал.

Теперь турбокомбайн работает идентично в Excel и Power BI:

— 120 запросов (скрины 1–2).
— 1023 функции в пайплайне (скрины 5–8).
— 94 уникальные функции.
— Одинаковая модель данных (скрин 3).
— 4500 уникальных строк кода.
— 88 листов А4 кода (скрин 4).

✅ Пользовательские значения и библиотеки заполняются в одном файле.
✅ Дальше в Excel и Power BI обработка данных идентична.
✅ Идентичная структура запросов в Excel и Power BI, отличия только в подключении к источнику.
✅ Отличия скорости:
— в 2 раза: Power BI обновляет запросы параллельно, Excel — последовательно.
— в 3 раза: если в Power BI не обновлять схему модели данных, а только данные, что нельзя отдельно сделать в Excel.

Из 76.000 неочищенных фраз получаем ~4000 чистых сгруппированных:

⏱️ В Power BI:
— 12:29 — только обновление данных.
— 17:08 — схема модели + данные.

⏱️ В Excel:
— 34:10 — схема + данные.

2 месяца сидел в коде ежедневно по 15 часов. Переделал десятки версий, добавил функционала, искал способы оптимизации. Ускорил на 20%, но это лишь погрешность. Больше всего на скорость обновления влияет объём данных. Самая медленная операция — чтение данных.

Нашёл и протестировал лучшие практики экспертов BI-индустрии, спецов со статусом MVP от Microsoft, авторов книг, курсов, блогов по Power BI, прошерстил справку по Power Query, перепробовал для оптимизации запросов сотни промптов в нейросетях, в т.ч. на платных тарифах.

Это привело лишь к незначительному приросту производительности либо вовсе к замедлению. С пайплайном из 1000+ функций всё сложно. Ускорения х50–500 не будет. Новые попытки тратить время на оптимизацию никогда себя не окупят.

Я всё это выстрадал за вас, чтобы не пришлось страдать вам.

Добавил:

✅ Параметризацию всех обрабатываемых объектов: полей, их количества, значений, списков, фильтров, сортировок, группировок и др.
✅ Три метода автогруппировки семантики. Можно использовать 1, 2 или 3 способа одновременно. Разница — в приоритете, чистоте и детализации. Каждый выбирает сам, в каком срезе использовать какой метод группировки.

✅ 50+ универсальных правил разметки униграмм.
✅ Тысячи замен синонимов на единые написания.
✅ Десятки тысяч значений в глобальной библиотеке для разметки.
✅ 100+ регулярных выражений для разметки.
✅ Регулярки извлекают значения, ряд правил заменяет их на единые написания для унификации и универсализации разметки, фильтрации, приоритизации, сортировки, группировки и избегания излишнего дробления кластеров.

✅ Поддержка пользовательской библиотеки для разметки униграмм. Изменяешь разметку в локальной библиотеке по текущему проекту — пересчитывается весь пайплайн.

✅ После фильтрации семантики вайтлистом обрабатываются и группируются только целевые сегменты, мусор не обрабатывается вовсе для повышения производительности.

✅ Изменён приоритет библиотек при разметке:
— Локальная (по текущему проекту).
— Глобальная (по всем проектам).
— Универсальные правила.
— Регулярки.

✅ Теперь регулярки обрабатывают в сотни раз меньше данных после фильтрации 50 правилами, проходя по остаткам того, что не обработано правилами. В разных проектах это могут быть как сотни, так и сотни тысяч уникальных значений. Разница в производительности на таких массивах — огромна.

Также добавлены:

✅ Введение пользовательских значений для гибкого управления комбайном.
✅ Автоприоритизация сегментов.
✅ Автоконсолидация статистики по неявным дублям.
✅ Автоопределение по показателям самой частотной словоформы каждого неявного дубля.
✅ Автопересчёт показателей на разных уровнях группировки данных.
✅ Универсализация схемы нейминга вычисляемых полей.
✅ Автосоздание и автопересчёт вычисляемых полей.
✅ Автозамена синонимов на единые написания с последующим обновлением всего пайплайна, автовычислением приоритета сегментов и их перегруппировкой.

Что дальше:

⚡️ Автосборка РК для Гугла и Яндекса.
⚡️ Автодобавление в РК новой семантики.
⚡️ Морфологический анализ на Python, встроенном в Power BI, для фильтрации и группировки семантики.

✅ Читать продолжение.

via @ppc_bigbrain

(1/4) Вы теряете 20–50% трафика по самым частотным ключам в Директе.

И это не кликбейт.

Используя в семантике на поиске Яндекс Директ в [квадратных] [скобках] только одну словоформу из всех, отличающихся отсутствием или наличием разных предлогов, вы теряете:

❌ От 18–20% трафика — в среднем по всему аккаунту.

❌ До 30–50% трафика — по отдельным самым частотным ключевым фразам.

Это касается всех без исключения.

Пост разделён на несколько частей, но суть проблематики — на скриншотах в этом посте.

По уже давно сложившейся традиции, продолжаю оцифровывать то, о чём не говорит никто в PPC индустрии, и уж тем более — не считает.

Предыстория:

🔣 У поста про квадратные скобки в Яндекс Директе, который я опубликовал более 2 лет назад, уже 8356 просмотров и 634 репоста.

🔣 У поста про аналитику квадратных скобок, написанного 8 месяцев назад — 6246 просмотров и 338 репостов.

Всё больше специалистов используют квадратные скобки, индустрия исцеляется, рекламодатели точнее управляют поисковыми запросами, Яндекс меньше вращает ваши бюджеты на детородном органе.

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

В чём же суть проблемы?

Используя фиксацию [каждого] [слова] в [квадратных] [скобках], НЕЗАВИСИМО от того, берёте ли вы предлоги в скобки или нет, они всё равно жёстко фиксируются в поисковых запросах ровно так же, как указано в ключевой фразе.

По всем остальным поисковым запросам вы не показываетесь НИКОГДА.

————

Что это значит?

Ключевая фраза в аккаунте:

✅ [купить] [пластиковые] [окна] в [москве] — предлог "в" НЕ закреплён в [скобках].

и / или:

✅ [купить] [пластиковые] [окна] [в] [москве] — предлог "в" закреплён в [скобках].

В обоих случаях все 100% показов приходятся на поисковые запросы ТОЛЬКО с обязательным вхождением конструкции "в москве". При этом фиксация предлога в скобках значения не имеет.

Откройте свои отчёты о поисковых запросах, и вы не найдёте ни одной строки, в которой в [ключевой] [фразе] с [квадратными] [скобками] будет присутствовать предлог, не зависимо от того, находится ли он в скобках, а в поисковом запросе — нет.

По каким поисковым запросам (в рамках этой ключевой фразы) вы при этом не покажетесь НИКОГДА? — По запросам, которые содержат только топоним "москва" без предлога "в", т.е. в этом случае, например:

🚫 купить пластиковые окна москва (перед москвой нет предлога "в")

————

Далее поговорим:

— О масштабах этой проблемы, и как она влияет на перфоманс конкретных кластеров семантики, если использовать квадратные скобки.

— О том, как использовать квадратные скобки, чтобы не потерять трафик по самым частотным поисковым запросам в нише.

— Как это реализовано и полностью автоматизировано у меня в комбайне до нуля кликов.

⬇️ Читать продолжение в следующем посте.

via @ppc_bigbrain

(2/4) Вы теряете 20–50% трафика по самым частотным ключам в Директе.

Продолжение части 1.

Начнём с используемой далее терминологии:

❓ Стоп-слова — служебные части речи: предлоги, союзы, частицы, местоимения, артикли (в иностранных языках).

❓ Лемма — начальная словарная форма слова.

❓ Лемма фразы — фраза, в которой все слова приведены к леммам.

❓ Лемма фразы без учёта стоп-слов — лемма фразы, из которой удалены все стоп-слова.

❓ Лемма фразы без учёта порядка слов — лемма фразы, в которой слова в строке отсортированы в едином порядке по всему массиву — применяется для обнаружения неявных дублей, отличающихся словоформами и порядком слов.

❓ Маска фразы — лемма фразы без учёта стоп-слов и порядка слов — лемма фразы, в которой удалены все стоп-слова и слова отсортированы в строке в едином порядке по всему массиву — применяется для обнаружения неявных дублей, отличающихся словоформами, порядком слов, а также наличием или отсутствием стоп-слов.

Если вы когда-либо в Кейколлекторе или Директ Коммандере удаляли неявные дубли фраз, в которых стоп-слова не закреплены операторами соответствия "!", "+" или [ ] — это и есть удаление дублей масок — лемм фраз без учёта стоп-слов и порядка слов.

Слова в строке можно отсортировать тремя способами:

1️⃣ По алфавиту — проще и быстрее, но это невозможно читать в дальнейшей работе.

2️⃣ По убыванию показателей — т.е. чем частотнее слово, тем оно левее в строке, это уже чуть более универсально, налево сдвигаются более важные в лексике ниши слова, но всё-равно слова в строке находятся в хаотическом порядке, никакой упорядоченности, результаты такой сортировки невозможно читать при дальнейшей работе.

3️⃣ По показателям и по смыслу — визуально воспринимать проще всего, используя многоуровневую сортировку с классификацией слов:
🥷 По охвату групп ярлыков.
🥷 Внутри групп ярлыков — по охвату смысловых ярлыков слов.
🥷 Внутри смысловых ярлыков — по охвату синонимичных замен.
🥷 Внутри замен — по охвату лемм слов.

Получаем сортировку слов в строке по смыслу и приоритету в нише. Она используется лишь как промежуточный шаг, чуть более удобный для восприятия.

Специально отсортировал таблицу на скринах 1 и 2 не по показателям, а по алфавиту — для наглядности, почему такая смысловая группировка и сортировка слов в строке удобнее и легче для чтения.

✅ Скрин 1 — группы ярлыков (без стоп-слов) — независимо от порядка слов в исходной фразе, группы ярлыков расположены в строке всегда в одном и том же порядке. Для простоты понимания этой концепции выделил одинаковые группы ярлыков в столбце одинаковыми цветами.

✅ Скрин 2 — смысловые ярлыки (без стоп-слов) — аналогичный порядок в строке, что и выше.

✅ Скрин 3 — синонимичные замены (без стоп-слов) — аналогичный порядок в строке, что и выше.

✅ Скрин 4 — маски фраз (т.е. леммы БЕЗ стоп-слов и порядка слов).

✅ Скрин 5 — самая частотная словоформа каждой маски фразы БЕЗ учёта стоп-слов.

✅ Скрин 6 — самая частотная словоформа каждой леммы СО стоп-словами. Это группировка до единого самого частотного варианта всех написаний каждой фразы:

— С любым порядком слов.
— С наличием или отсутствием стоп-слов.
— С любыми словоформами каждого слова.

Наличие стоп-слов в ключах в широком соответствии на охват не влияет, но использование в [квадратных] [скобках] неправильно выбранной не самой частотной словоформы с учетом стоп-слов может сильно урезать трафик.

Даже при сортировке фраз по показателям и отборе самой частотной формы с предлогами можно лишиться до 30–55% охвата.

А что если не глядя взять в РК не самую частотную словоформу?

На последнем скрине есть словоформы с индексом 2 и более, у которых 1% охвата маски фразы.

✅ Решение проблемы:

Брать в [скобки] в РК не одну самую частотную словоформу с предлогом или без (на последнем скрине — столбец "ВЧ_Формы_БезСтоп"), а все частотные словоформы с предлогами (столбец "ВЧ_Формы_СоСтоп").

Далее рассмотрим, насколько всё плохо:

1️⃣ В масках фраз, у которых две и более словоформ с учётом стоп-слов.
2️⃣ В отдельных кластерах семантики.

⬇️ Читать продолжение.

via @ppc_bigbrain