Верно, модель процессов построена на PO, которых начинают холить и лелеять в духе печенек, и коучить: «ты хозяин, это твое, управляй как хочешь». То есть по сути, создают некий виртуальный мир, не позволяющий им оглянуться, и просто понять — что за те же деньги, с них фактически спрашивают топовскую ответственность.
Эта «золотая» клетка работает, спору нет. Но если абстрагироваться от этого, и посмотреть цинично на ситуацию — то становится как-то… противно что-ли? И жалко людей, сидящих в «золотых клетках» :)
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 не будет принимать ивенты от приложения?
Эта «золотая» клетка работает, спору нет. Но если абстрагироваться от этого, и посмотреть цинично на ситуацию — то становится как-то… противно что-ли? И жалко людей, сидящих в «золотых клетках» :)
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 — нормальный механизм, позоляющий собственнику вести сквозь рынок компанию по приборам, а не в творческом полете собственных ощущений. Просто нужно уметь ими пользоваться.
Мое мнение простое: есть проблема — приходи, обсудим предметно.