የህይወት ዑደት (በአገልጋይ በኩል)

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`	Website → Site Tracking፣ ከክስተት ቁልፉ ጎን
Mailchimp	የታዳሚ ID	የAPI ቁልፍ — እንደ `-us14` ያለውን ቅጥያ ያቆዩ፣ የውሂብ ማዕከሉ ከእሱ ይነበባል
Iterable	አያስፈልግም — ባዶ ይተዉት	«Allow event track calls» ፈቃድ ያለው ቁልፍ
Klaviyo	አያስፈልግም — ባዶ ይተዉት	የ ግል API ቁልፍ

ሶስተኛው መስክ የሚታይበት የክስተት ስም ነው። አጭር ያድርጉት፦ ከፍተኛው 32 ቁምፊዎች። ይህ የAPIው ገደብ ነው፣ የእኛ አይደለም፣ በሚላክበት ጊዜ ሳይሆን ሲያስቀምጡ እናሳጥረዋለን — ካልሆነ ቅጹ ከሚደርሰው የተለየ ነገር ያሳይዎታል።

Mailchimp፦ በAPI ቁልፍዎ ላይ ያለውን ቅጥያ ያቆዩ። ከመጨረሻው ሰረዝ በኋላ ያለው ክፍል (-us14) መለያዎ ያለበትን የውሂብ ማዕከል ይሰይማል፣ አድራሻውም ከእሱ ይገነባል። ያለ እሱ ያለ ቁልፍ ማየት በማይችሉበት ቦታ ከመክሸፍ ይልቅ በግልጽ መልዕክት ይከለከላል።

3. መቼ ይነሳል — መቼስ አይነሳም

የክፍለ ጊዜ ማንነት በሚለይበት ጊዜ፦ ድረ ገጽዎ MousePlayer.setUserId() ሲጠራ፣ የትንተና ማገናኛ ድልድያችን ልዩ ID መልሶ ሲያነብ ወይም አገልጋይዎ identify የመጨረሻ ነጥቡን ሲጠራ። ከዚያ በፊት ቀረጻው የማን እንደሆነ አናውቅም።

በኢሜይል አድራሻ ብቻ

አራቱም መድረኮች እውቂያን በኢሜይሉ ያነጋግራሉ። የደንበኛ 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 ከእነዚህ አቅራቢዎች ጋር የንግድ ግንኙነት የለውም።

እንዴት ልንረዳዎ እንችላለን?