1. Да, так можно, но это уже не нативно. То есть ухудшение, по сравнению с текущей версией GA.
2. А BQ — это что?
3. Owox — платная история. А нам, чтобы выдернуть данные через Reporting API достаточно было пары дней работы программиста. То есть отсутствие Reporting API — тоже ухудшение. Но тут есть еще один лайфхак — это сделать «пропуск» всего трафика через свой сервер (можно указать свой endpoint), а свой сервер сохраняет нужную статистику, и переадресует запрос на GA. Но у этого способа есть несколько минусов.
Чем больше я смотрю на процессы, описанные в данной статье, и чем больше я наблюдаю изнутри такого процесса трансформации, тем больше не могу отделаться от вот какого впечатления.
Было:
Собственник — CIO/CPO. Для собственника — CIO/CPO отвечает за конечный результат. CIO/CPO является стороной, страдающей от «перекидывания через забор».
Стало:
Собственник — CIO/CPO — команды продуктов. Теперь команда продуктов делает конечный результат, и занимается внутренним разбирательством «перекидываний через забор», которые в сущности никуда не делись.
То есть проблемы просто делегированы и разбиты на более мелкие.
Что в итоге?
Собственник — ничего не меняется.
CIO/CPO — становится теперь не виноватым, и «как бы» собственником, не организующим процесс, а спрашивающим за результат со следующего уровня ответственности.
PO — те боевые лошадки, на которых теперь помимо продукта падает ответственность за организацию работ так, чтобы не было «перекидываний за забор».
Пока еще очень сырой продукт. Из того, что было, и что критически важно:
1. Нельзя передавать IP-адрес (даже анонимизированный) и флаг ip_override. Причины понятны, но нельзя собирать теперь статистику через сервер.
2. Нельзя передавать флаг app. Раньше можно было диффеенцировать, откуда посылаем события (или хиты), указывая определенные флаги. Теперь это сделать нельзя, и приложение вынуждено «прикидываться» web-приложением.
3. Нет пока reporting api. И не факт — что появится. Придется извращаться через bigquery. :(
В общем, с одной стороны — все упростили. С другой — сузили возможности :(
А можно ли использовать эти системы, как продуктовый каталог для Интернет-магазинов? То есть не делать хранение товаров в отдельном движке, скажем, opencart, а использовать PIM, и просто доделать всякие страницы типа «О магазине», «Корзина» и пр?
Вопрос связан с тем, что я последнее время думаю, что хорошо бы кроме интернет-магазина иметь еще возможность строить лендинги с подтягиванием продукта, а часть продуктов вынести на другие типа сайтов, например, оптовый. То есть иметь один мастер-истоник продуктов со сквозными id. Кажется, из того, что я прочел — PIM может решить такую задачу?
Если не выключать Vivaldi, то чрез некоторое время (2-3 дня) вентилятор начинал шарашить на полную, с гудением и разогревом. Если завершить Vivaldi, то еще на пару дней все было норм. Но проблема еще была в том, что при выходе (Cmd-Q) vivaldi подвешивал все так, что приходилось удерживать более 5 сек. кнопку Power.
Писал на форуме Vivaldi, толком никто ничего не сказал. Посоветовали только через комбинацию, кажется, Cmd-Esc открывать список вкладок с указанием загрузки CPU. Пробовал, но когда вентилятор шумел, потребление вкладками процессора было норм.
В итоге, я решил, раз за 8-9 месяцев, что я им пользовался, такие core-проблемы не решаются, а за исключением frendly-мелочей, явного преимущества у vivaldi нет — вернулся на FireFox. С которого сейчас и пишу.
Тогда такая гипотеза может формировать некорректное мнение. Я уже долго наблюдаю один ИМ, с конверсией 90%. Там уже некуда увеличивать. И тоже сложная форма. Но почти уникальный (редкий) товар.
Выдвигаю гипотезу, что на том сайте продается все дешево, люди дойдут до конца заказа, продравшись ради цены сквозь любые дебри форм. И конверсия близка к 100%. :)
Упрощение форм — это инструмент. Любой инструмент работает в каких-то конкретных условиях. Без указания этих условий, возможно дать неэффективную рекомендацию.
Эмммммм. А почему KPI-то виноваты? Если брать ситуацию с продажниками, то в указанном примере в нормальной компании вводят специализацию. Например, есть те, кто умеет продавать много, но по малу в каждой продаже. У них KPI за количество продаж. А есть те, кто делает 1-2 подажи, но большого объема. У них другие KPI.
KPI — нормальный механизм, позоляющий собственнику вести сквозь рынок компанию по приборам, а не в творческом полете собственных ощущений. Просто нужно уметь ими пользоваться.
Вы не поверите, я начальник отдела. Пришел человек из Яндекса, который сильно удивился, что нет one-to-one, и он без этого не может. В итоге — провожу (с ним only). Остальные — ржут.
Мое мнение простое: есть проблема — приходи, обсудим предметно.
Хм… Допустим, у меня есть приложение под Андроид. В него встроена SDK Google Analytycs. Решил расширить воронку, и выйти на AppGallery. Что произвойдет? Мне нужно выпилить SDK GA? Или SDK будет работать, но GA не будет принимать ивенты от приложения?
А что мешает в приложение, которые мы ставим в AppGallery, запилить GA и Firebase? Или Google понимает, что запущено МОЕ приложение на Huawei и режет аналитику?
2. А BQ — это что?
3. Owox — платная история. А нам, чтобы выдернуть данные через Reporting API достаточно было пары дней работы программиста. То есть отсутствие Reporting API — тоже ухудшение. Но тут есть еще один лайфхак — это сделать «пропуск» всего трафика через свой сервер (можно указать свой endpoint), а свой сервер сохраняет нужную статистику, и переадресует запрос на GA. Но у этого способа есть несколько минусов.
Было:
Собственник — CIO/CPO. Для собственника — CIO/CPO отвечает за конечный результат. CIO/CPO является стороной, страдающей от «перекидывания через забор».
Стало:
Собственник — CIO/CPO — команды продуктов. Теперь команда продуктов делает конечный результат, и занимается внутренним разбирательством «перекидываний через забор», которые в сущности никуда не делись.
То есть проблемы просто делегированы и разбиты на более мелкие.
Что в итоге?
Собственник — ничего не меняется.
CIO/CPO — становится теперь не виноватым, и «как бы» собственником, не организующим процесс, а спрашивающим за результат со следующего уровня ответственности.
PO — те боевые лошадки, на которых теперь помимо продукта падает ответственность за организацию работ так, чтобы не было «перекидываний за забор».
1. Нельзя передавать IP-адрес (даже анонимизированный) и флаг ip_override. Причины понятны, но нельзя собирать теперь статистику через сервер.
2. Нельзя передавать флаг app. Раньше можно было диффеенцировать, откуда посылаем события (или хиты), указывая определенные флаги. Теперь это сделать нельзя, и приложение вынуждено «прикидываться» web-приложением.
3. Нет пока reporting api. И не факт — что появится. Придется извращаться через bigquery. :(
В общем, с одной стороны — все упростили. С другой — сузили возможности :(
Вопрос связан с тем, что я последнее время думаю, что хорошо бы кроме интернет-магазина иметь еще возможность строить лендинги с подтягиванием продукта, а часть продуктов вынести на другие типа сайтов, например, оптовый. То есть иметь один мастер-истоник продуктов со сквозными id. Кажется, из того, что я прочел — PIM может решить такую задачу?
Писал на форуме Vivaldi, толком никто ничего не сказал. Посоветовали только через комбинацию, кажется, Cmd-Esc открывать список вкладок с указанием загрузки CPU. Пробовал, но когда вентилятор шумел, потребление вкладками процессора было норм.
В итоге, я решил, раз за 8-9 месяцев, что я им пользовался, такие core-проблемы не решаются, а за исключением frendly-мелочей, явного преимущества у vivaldi нет — вернулся на FireFox. С которого сейчас и пишу.
Выдвигаю гипотезу, что на том сайте продается все дешево, люди дойдут до конца заказа, продравшись ради цены сквозь любые дебри форм. И конверсия близка к 100%. :)
Упрощение форм — это инструмент. Любой инструмент работает в каких-то конкретных условиях. Без указания этих условий, возможно дать неэффективную рекомендацию.
KPI — нормальный механизм, позоляющий собственнику вести сквозь рынок компанию по приборам, а не в творческом полете собственных ощущений. Просто нужно уметь ими пользоваться.
Мое мнение простое: есть проблема — приходи, обсудим предметно.