MS
Попробую)
Size: a a a
2021 February 15
M
Интересно, есть ли урл, по которому сразу сюда можно провалиться?
V
Да, да
V
Или не то?
E
Или не то?
В реплаи
MS
MS
не все читаемо, надо в чат лезть
V
В реплаи
Ааааааа, неа
S
Ребят, а есть кто настраивал события по целям Вконтакте?
Хотим отслеживать цели, фиксировать их и передавать в пиксель вк, чтобы видеть эффективность, и отдельно по разным целям настраивать таргет
Есть проблема с событием достоверной фиксации факта оформления заказа.
1. Мы заказы принимаем на бэкэнде только после того, как клиент оплатит заказ
2. Используем yookassa
3. Клиент может уйти на оплату и не вернуться
4. → отслеживать достоверное состояние заказа мы можем только по факту получения события оплаты со стороны платёжного шлюза. Варианта
«Достижение URL» страницы Спасибо с подтверждением заказа — не годится
Яндекс Метрика для таких случаев разработала решение: передавать оффлайном с бэкэнда события оплаты по ClientID. То есть, когда человек идёт оплачивать, мы знаем его ClientID и крепим его в БД к заказу. Как только к нам на сервер прилетает событие из платёжного шлюза -> мы обновляем статус заказа и событие передаем в ClientID
У вк есть какие-то решения подобные, чтобы также достоверно фиксировать факт оплаты?
Хотим отслеживать цели, фиксировать их и передавать в пиксель вк, чтобы видеть эффективность, и отдельно по разным целям настраивать таргет
Есть проблема с событием достоверной фиксации факта оформления заказа.
1. Мы заказы принимаем на бэкэнде только после того, как клиент оплатит заказ
2. Используем yookassa
3. Клиент может уйти на оплату и не вернуться
4. → отслеживать достоверное состояние заказа мы можем только по факту получения события оплаты со стороны платёжного шлюза. Варианта
«Достижение URL» страницы Спасибо с подтверждением заказа — не годится
Яндекс Метрика для таких случаев разработала решение: передавать оффлайном с бэкэнда события оплаты по ClientID. То есть, когда человек идёт оплачивать, мы знаем его ClientID и крепим его в БД к заказу. Как только к нам на сервер прилетает событие из платёжного шлюза -> мы обновляем статус заказа и событие передаем в ClientID
У вк есть какие-то решения подобные, чтобы также достоверно фиксировать факт оплаты?
S
Ходил в их документацию — там не описано как быть с таким кейсом, когда человек может уйти на страницу платежа, оплатить и не вернуться на сайт
A
Ребят, а есть кто настраивал события по целям Вконтакте?
Хотим отслеживать цели, фиксировать их и передавать в пиксель вк, чтобы видеть эффективность, и отдельно по разным целям настраивать таргет
Есть проблема с событием достоверной фиксации факта оформления заказа.
1. Мы заказы принимаем на бэкэнде только после того, как клиент оплатит заказ
2. Используем yookassa
3. Клиент может уйти на оплату и не вернуться
4. → отслеживать достоверное состояние заказа мы можем только по факту получения события оплаты со стороны платёжного шлюза. Варианта
«Достижение URL» страницы Спасибо с подтверждением заказа — не годится
Яндекс Метрика для таких случаев разработала решение: передавать оффлайном с бэкэнда события оплаты по ClientID. То есть, когда человек идёт оплачивать, мы знаем его ClientID и крепим его в БД к заказу. Как только к нам на сервер прилетает событие из платёжного шлюза -> мы обновляем статус заказа и событие передаем в ClientID
У вк есть какие-то решения подобные, чтобы также достоверно фиксировать факт оплаты?
Хотим отслеживать цели, фиксировать их и передавать в пиксель вк, чтобы видеть эффективность, и отдельно по разным целям настраивать таргет
Есть проблема с событием достоверной фиксации факта оформления заказа.
1. Мы заказы принимаем на бэкэнде только после того, как клиент оплатит заказ
2. Используем yookassa
3. Клиент может уйти на оплату и не вернуться
4. → отслеживать достоверное состояние заказа мы можем только по факту получения события оплаты со стороны платёжного шлюза. Варианта
«Достижение URL» страницы Спасибо с подтверждением заказа — не годится
Яндекс Метрика для таких случаев разработала решение: передавать оффлайном с бэкэнда события оплаты по ClientID. То есть, когда человек идёт оплачивать, мы знаем его ClientID и крепим его в БД к заказу. Как только к нам на сервер прилетает событие из платёжного шлюза -> мы обновляем статус заказа и событие передаем в ClientID
У вк есть какие-то решения подобные, чтобы также достоверно фиксировать факт оплаты?
неужели у них нет вебхука по факту успешной оплаты?
A
чтобы дергался ваш бек, без всяких "вернуться к продавцу"
S
неужели у них нет вебхука по факту успешной оплаты?
У них — у ВК или у Метрики?
A
у юкассы
A
а, сорри, не вчитался... у юкассы как раз есть и вы хотите такоеже для ВК
V
goreplay?
оно))) я нашел)
V
наконец-то
S
чтобы дергался ваш бек, без всяких "вернуться к продавцу"
ну, бэк то дёргается ЮКассой
Вся проблема в другом: как передать информацию Вконтакте/Метрике какому пользователю нужно присвоить это событие?) Ведь оно не на нашем сайте происходит онлайн. В метрике для этого сделан ClientID.
И вот непонятно как это Вконтакте работает
Вся проблема в другом: как передать информацию Вконтакте/Метрике какому пользователю нужно присвоить это событие?) Ведь оно не на нашем сайте происходит онлайн. В метрике для этого сделан ClientID.
И вот непонятно как это Вконтакте работает
A
ну, бэк то дёргается ЮКассой
Вся проблема в другом: как передать информацию Вконтакте/Метрике какому пользователю нужно присвоить это событие?) Ведь оно не на нашем сайте происходит онлайн. В метрике для этого сделан ClientID.
И вот непонятно как это Вконтакте работает
Вся проблема в другом: как передать информацию Вконтакте/Метрике какому пользователю нужно присвоить это событие?) Ведь оно не на нашем сайте происходит онлайн. В метрике для этого сделан ClientID.
И вот непонятно как это Вконтакте работает
а метрику нельзя с бека дёрнуть через апи?