Животен циклус (на страната на серверот)
Испратете ја врската до репродукцијата во ActiveCampaign, Mailchimp, Iterable или Klaviyo од нашиот сервер во моментот кога сесијата ќе го добие вашиот ID на клиентот.
1. Зошто ова постои покрај мостот во прелистувачот
MousePlayer веќе има мост за животен циклус што запишува во SDK на вашата страница - Klaviyo, Braze, Customer.io и уште шест други. Овој ја извршува истата задача од нашиот сервер и постои бидејќи за две од најголемите платформи начинот преку прелистувач едноставно не е достапен:
- ActiveCampaign воопшто нема API за настани во прелистувачот. Неговиот
vgo()може да постави сметка и адреса за е-пошта и да започне со следење - не може да испрати настан. Настаните одат преку Event Tracking API со посебен клуч за настани, само од серверот. - Mailchimp има таков, но со затворен речник. Неговиот пиксел за следење веб-локација прифаќа
PAGE_VIEWED,PRODUCT_VIEWED,PURCHASEDи неколку други однапред дефинирани имиња. Нема место за приспособен настан, а притискањето на нашите податоци воPAGE_VIEWEDби било лага во вашиот сопствен модел на податоци.
За Iterable и Klaviyo серверскиот начин едноставно е поверодостоен: нема блокатор на реклами, нема SDK што можеби се вчитал, а можеби не, нема прерано затворање на картичката.
2. Што му треба
Три полиња, а кои ги пополнувате зависи од платформата.
| Платформа | Поле за сметка | Клуч |
|---|---|---|
| ActiveCampaign | actid | Веб-локација → Следење веб-локација, покрај клучот за настани |
| Mailchimp | ID на публиката | API-клуч - задржете го неговиот суфикс од типот -us14 , од него се чита центарот за податоци |
| Iterable | не е потребно - оставете празно | Клуч со дозволата „Дозволи повици за следење настани“ |
| Klaviyo | не е потребно - оставете празно | Еден приватен API-клуч |
Третото поле е името на настанот под кое ќе се појави. Нека биде кратко: најмногу 32 знаци. Тоа е ограничувањето на API, а не наше, и го скратуваме при зачувувањето, а не при испраќањето - инаку формуларот би ви покажувал нешто различно од она што пристигнува.
Mailchimp: задржете го суфиксот на API-клучот. Делот по последната цртичка (-us14) го именува центарот за податоци на вашата сметка и од него се гради адресата. Клуч без него се одбива со јасна порака наместо да откаже некаде каде што не можете да видите.
3. Кога се активира - и кога не
Во моментот кога сесијата е идентификувана: кога вашата веб-локација повикува MousePlayer.setUserId(), кога нашиот аналитички мост ќе прочита единствен ID или кога вашиот сервер ќе ја повика крајната точка за идентификација. Пред тоа не знаеме кому припаѓа снимката.
Само со адреса за е-пошта
Сите четири платформи го адресираат контактот преку неговата е-пошта. Ако вашиот ID на клиентот е број на договор, ништо не се испраќа - ставање задача што може само да не успее во редицата би го наполнило дневникот со шум.
Контактот веќе мора да постои. Ниту една од овие платформи не создава контакт од настан; ActiveCampaign целосно го отфрла настанот ако не ја препознава адресата. Овој мост ги збогатува постојните контакти - не го гради вашиот список.
Секој настан носи ID
За истата сесија да не може да се изброи двапати, дури и ако задачата се повтори.
4. Што пристигнува на другата страна
Еден настан што ја содржи врската до репродукцијата како својство именувано mouseplayer_session_url. Отворете го и сте во снимката на токму таа сесија.
Оттаму важи логиката на самата платформа: користете го настанот како активатор на автоматизација, како услов за сегмент или едноставно дозволете му на тимот да ја отвори снимката од контактот.
Клучот никогаш не го напушта нашиот сервер
Се чува шифриран со AES-256-GCM, никогаш повторно не се прикажува по зачувувањето и намерно не се става во внатрешната редица што ја носи задачата - работниот процес сам го презема од базата на податоци.
HTTP 200 не значи доставено
ActiveCampaign одговара со статус 200 и {"success":0} кога одбива настан. Го читаме телото на одговорот, а не само статусот, па одбивањето се појавува како неуспех во дневникот на доставувања наместо како незабележлив успех.
5. Braze, Customer.io и Brevo
Уште три платформи на серверскиот начин. На две од нив им треба нешто што на другите не им треба: место.
| Наведувате | Идентификувано преку | |
|---|---|---|
| Braze | REST-крајна точка и API-клуч | адреса за е-пошта |
| Customer.io | ID на веб-локацијата, API-клуч и вашиот регион | вашиот сопствен ID на клиентот |
| Brevo | само клучот на следачот | адреса за е-пошта |
Две од нив се на конкретно место
Braze користи REST-крајни точки врзани за инстанца; Customer.io користи два одделни региони со различни домаќини. Ниту едното не може да се изведе од клучот, а погрешниот избор одговара со 401 - што ве наведува да го проверувате клучот. Двете полиња постојат само поради таа причина.
Customer.io е оној што не бара е-пошта
Ги препознава луѓето според истиот ID што вие им го доделувате, па барањето адреса за е-пошта би било измислена пречка. Другите шест се совпаѓаат според е-пошта и за нив сесија идентификувана со број на договор не создава ништо - правилно.
Нема нови профили
Повикот до Braze содржи _update_existing_only. Истата одлука како кај CRM-мостот: сесија во прелистувач не е веродостоен показател за тоа кои се вашите клиенти, а платформа за животен циклус што создава профил за секој анонимен посетител е полоша од никаква интеграција.
Brevo одговара со 204, Braze одговара со 201 со една замка
Brevo воопшто не враќа тело - таму 2xx навистина е целата вистина. Braze враќа "message": "success" и може покрај него да содржи низа errors : фаталните проблеми се појавуваат во пораката, а толерираните загуби на полиња само во errors. Читањето само на едното дава погрешен резултат во една или друга насока.
Сите трговски марки наведени тука им припаѓаат на нивните соодветни сопственици. MousePlayer нема деловен однос со овие даватели.