B2B etkinliği verileri CRM'e nasıl aktarılır

B2B etkinliği verilerinin CRM'e aktarım şeması: varlıklar, ID'ler, durumlar, alanlar, onaylar, kopya kayıtlar ve alınan kaydın doğrulanması.

İşletmelere yönelik etkinliklerin (B2B, business-to-business) verileri çoğu zaman mekân ile CRM - müşteri ilişkileri yönetimi sistemi - arasında anlamını yitirir. Formda ad ve e-posta vardır, yaka kartında bir numara belirir, tarayıcı bir işlemi kaydeder, ancak hedef sistemde anlaşılır bir etkinlik, oturum, görüşme veya davet kaynağı olmadan yeni bir kişi kalır.

Biz Aventura olarak işe diğer taraftan başlıyoruz: müşterinin sistemine ulaşması gereken olguları tanımlıyor ve CRM'in bunların alındığını nasıl onaylayacağı üzerinde anlaşıyoruz. Böyle bir sözleşme kayıt açılmadan önce gereklidir. Sonradan tanımlayıcıları (ID), durumları ve alanların amacını değiştirmek belirgin şekilde daha zordur: veriler artık aynı anda birkaç noktadan akıyor.

Eğer bir iş etkinliği hazırlıyorsanız ve kaydı, varış işaretlemesini (check-in) ve mekândaki aktiviteleri önceden müşterinin sistemiyle ilişkilendirmek istiyorsanız, proje için bir çalışma görüşmesi talep edin. Etkinlik veri şemasını ve ortak test gereksinimlerini tanımlamaya yardımcı oluruz. CRM'in kurulumu ve yönetimi müşterinin ilgili ekibinde kalır.

CRM'e hangi veriler girmelidir?

Yalnızca CRM'de belirli bir eylemi destekleyen verileri iletin. Her alan ve olgu için amacı, sahibini ve alıcısını önceden belirtin. Ekip, değeri kimin kullandığını ve ardından ne yaptığını açıklayamıyorsa, alanı formdan veya veri alışverişinden çıkarmak daha iyidir.

B2B etkinliğinin birden fazla kaynağı vardır. Davet, kampanyayı ve geçiş kanalını verir. Kayıt, kimin katılım başvurusunda bulunduğunu bildirir.

Varış işareti katılımı doğrular. Bir oturum, toplantı veya standdaki eylem yeni bir olgu ekler. CRM bu parçaları ortak bağlamla almalı, ancak bunları tek bir nesnede saklamak zorunda değildir.

Her kaynağa sorulacak asgari soru şöyledir:

UTM (Urchin Tracking Module) etiketleri, geçişin kaynağını, kanalını ve kampanyasını ayırt etmeye yardımcı olur. Bunlar kayıt bağlamına aittir ve kişi veya başvuru tanımlayıcısının yerini almaz. Yaka kartı numarası da evrensel bir anahtar olmamalıdır: görevi belirli bir proje ve erişim yöntemiyle sınırlıdır.

Kayıt ve 152-FZ gereklilikleri hakkındaki ayrı makale, formun hukuki ve organizasyonel yönünü ele alır. Burada daha dar bir sınır çiziyoruz: hangi varlıklar ve alanlar CRM'de kabul edilen kayda kadar olan yolu izler.

Tek bir aşırı yüklenmiş kişi yerine beş varlık

Kişi, şirket, kayıt, katılım ve etkinlik farklı sorulara yanıt verir. Bunları tek bir kişi kartında birleştirip alanları sürekli üzerine yazarsanız sistem geçmişi kaybeder. İlişkili kayıtlar olguların sırasını korur ve her aktarımın ayrı ayrı doğrulanmasını sağlar. Böylece ekip yalnızca kişinin mevcut durumunu değil, katılımcının belirli bir etkinlikteki yolculuğunu da görür.

Kişi (Person) - katılımcının ana kaydıdır. Ana kayıtta kalıcı iletişim bilgileri ve kabul edilmiş tanımlayıcılar bulunur. Kişi birden fazla etkinliğe katılabilir, birkaç kez kayıt olabilir ve farklı işlemler gerçekleştirebilir.

Şirket (Company) - kuruluştur. Şirket her durumda e-posta alan adına eşit değildir, bu nedenle ilişkilendirme kuralı onaylanmalıdır. Kurumsal alan adı güçlü bir işaret olabilir. Genel amaçlı e-posta, bağlı ortaklık veya danışman farklı bir karar ve bazen manuel kontrol gerektirir.

Kayıt (Registration) - kişinin belirli bir etkinliğe başvurusudur. Kendi ID'si, event ID'si, kaynağı, oluşturulma zamanı ve durumu vardır. Aynı kişinin başka bir etkinliğe tekrar katılması yeni bir kişi değil, yeni bir kayıt oluşturur.

Katılım (Attendance) - hazır bulunma olgusudur. Kayıt, ziyareti kanıtlamaz. Microsoft Customer Insights da event registration ile check-in'i ayırır; üstelik check-in tüm etkinliğe veya tek bir oturuma ait olabilir. Bu nedenle «kayıtlı» ve «katıldı» alanları eşanlamlı sayılamaz.

Etkinlik (Activity) - ayrı bir işlemdir: oturuma katılım, görüşme, materyal taraması, standa ziyaret veya başka bir mutabık kalınmış olgu. Etkinlik kendi ID'sini, türünü, zamanını ve bağlamını saklar. HubSpot Meetings API aynı mantığı izler: görüşme ayrı bir CRM etkinliği olarak var olur ve kişilerle şirketlere bağlanır.

Bu model tüm CRM'lerde aynı yapıyı gerektirmez. Bir sistemde kayıt ayrı bir nesne, diğerinde kampanya katılımı, etkinlik ise işlem akışındaki bir kayıt olur. Anlam, hangi teknik gösterim olursa olsun korunmalıdır.

Tüm yolculuk için tanımlayıcı sistemi

Her nesne ve olgunun ayrı ve kalıcı bir ID'si olmalıdır. Kaynak, tanımlayıcıyı bir kez üretir; sonraki sistemler ise onu yeniden oluşturmadan iletir. Böylece tekrarlanan teslimat, tekrar olarak tanınır ve ekip aynı kaydı formda, veri alışverişi günlüğünde ve CRM'de bulabilir.

Çalışma seti şunları içerebilir:

1. event_id - belirli bir etkinlik.
2. person_id - kişinin mutabık kalınan kapsamdaki ana kaydı.
3. company_id - müşterinin sistemindeki veya alışveriş rehberindeki kuruluş.
4. registration_id - kişinin bu etkinliğe başvurusu.
5. attendance_id - ayrı check-in olgusu.
6. activity_id - oturum, toplantı, stand veya başka bir eylem.
7. source_system - olguyu oluşturan sistem.
8. schema_version - veri sözleşmesinin sürümü.

RFC standardı, merkezi kayıt olmadan üretilebilen evrensel olarak benzersiz 128 bitlik bir tanımlayıcı olan UUID'yi tanımlar. Form, mobil uygulama ve sahadaki ekipmanı farklı sistemler yönettiğinde bu kullanışlıdır. UUIDv7 ayrıca zamansal sıralamayı destekler, ancak belirli sürüm ikincildir. Kritik olan başka bir şeydir: üretim kurallarını tek bir ekip belirler ve tüm katılımcılar değeri korur.

CloudEvents spesifikasyonu, faydalı bir olay iletim modeli sunar. source + id çifti ayrı bir olayı tanımlar ve yeniden gönderilen olgu aynı ID'yi koruyabilir. Alıcı böylece ad, e-posta ve zamana dair tahmin yürütmeden tekrarı tanır.

Önemli. İletilen olgunun tanımlayıcısı, kişinin tanımlayıcısına veya etkinliğin event_id'sine eşit değildir. Adobe XDM ExperienceEvent olay modeli, olay kaydının _id'si ile kişinin identity'sini açıkça ayırır. Bir katılımcı birçok aktivite üretebilir ve her biri kendi tanımlayıcısını alır.

Konferans veya forumda bu yaklaşım özellikle faydalıdır: kayıt, genel giriş, oturum katılımı ve planlanan görüşmeler projenin farklı bölümlerinden gelir, ancak ortak event_id ve person_id etrafında toplanır. Böylece ekip, farklı varlıkları kişi kartında karıştırmadan her olgunun yolculuğunu doğrulayabilir.

Etkinliğin veri şeması, yükleniciler formları, yaka kartlarını ve tarayıcıları yapılandırmadan önce mutabık kalınmalıdır. Veri şeması görüşmesi ve ön tahmin için talepte bulunun. Etkinliğin temas noktalarını tek bir teknik şartnamede birleştirir ve müşteri tarafındaki CRM sahibiyle birlikte test yaparız.

Statüler üzerinde nasıl anlaşılır?

Bir statünün kodu, tanımı, sahibi ve izin verilen geçişleri olmalıdır. «Geldi», «katıldı» veya «ilgilendi» gibi serbest metinler hızla anlam kaymasına uğrar. Sözlük, hangi olgunun durumu değiştirdiğini ve CRM'in ne aldığını sabitler. Kayıt, katılım ve görüşmeler için ayrı sözlükler, aynı kelimenin farklı olayları ifade etmesini önler.

Ayrı sözlüklerle başlayın. Kayıt statüleri, katılım statüleri ve görüşme sonuçlarıyla karıştırılmamalıdır.

Tablodaki adlar yapı örneği olarak hizmet eder. Nihai kodları müşteri ekibi seçer. CRM'de zaten bir sözlük varsa, gönderici açık bir eşleme aracılığıyla ona uyum sağlar. Gönderici kendi sözlüğünü kullanıyorsa, eşleme her karşılığı ve bilinmeyen değer için davranışı göstermelidir.

Her statü için dört kural yazın:

1. Hangi gözlemlenebilir olgu onu belirler.
2. Değeri kimin değiştirme yetkisi vardır.
3. Önceki duruma dönülebilir mi.
4. Geç veya tekrarlanan bir olayda ne olur.

Örneğin, checked_in girişte kabul edilen bir taramadan sonra ortaya çıkar. Aynı attendance ID'nin tekrar taranması ikinci bir katılım oluşturmaz. Geç kayıt iptali, müşteri politikası geçmişi saklamayı gerektiriyorsa, zaten onaylanmış mevcudiyet olgusunu silmez.

Kampanya sırasında mevcut bir kodun değerini değiştirmeyin. Yeni bir şema sürümü ekleyin ve geçiş konusunda anlaşın. Aksi halde değişiklikten önce ve sonra aynı status=confirmed farklı anlamlara gelecektir.

Alan ve bağlam haritası nasıl oluşturulur?

Alan haritası, kaynağı ve CRM'i ad, tür, zorunluluk, dönüşüm ve hata durumundaki davranış düzeyinde birbirine bağlar. Yalnızca sütun listesi yeterli değildir. Alıcı, değerin nereden geldiğini ve hangi varlığa ait olduğunu anlamalıdır. Tartışmalı alanlar için referans listesi, şema sürümü, karar sahibi ve hatalı değer durumunda sistemin yanıtı hemen kaydedilir.

HubSpot Properties API, veri türü ile alan arayüzü arasındaki farkı iyi gösterir. Metin, tarih, sayı ve enumeration farklı şekilde saklanır. Durum referans listesi için metin alanı değil, sınırlı bir değer kümesi uygundur. Kendi harici ID'si, hedef CRM böyle bir modu destekliyorsa benzersizlik gereksinimi olan bir alana taşınabilir.

Asgari alan haritası şöyle görünür:

Bağlam özellikle stant için önemlidir. Tek bir badge_number=1842 aktarımı alıcıya hiçbir şey söylemez. Etkinlik ID'si, aktivite ID'si, eylem türü, zaman, tarama kaynağı ve kişi veya kayıt ID'si gerekir. Katılımcı belirli bir materyal talep ettiyse, materyal kodu alıcıda mutabık kalınmış bir eylem varsa ayrı bir alanda iletilir.

Fuar katılımı için harita yalnızca genel kaydı kapsamamalıdır. Bunda bölgeler, stantlar, tarayıcılar ve farklı veri sahipleri ortaya çıkar. Kaynak sayısı arttıkça tek bir source_system, şema sürümü ve reddedilen kayıtlar günlüğü daha da önemli hale gelir.

Minimizasyon kuralları izin veriyorsa, özgün değeri dönüştürülmüş değerin yanında saklamak faydalıdır. Böylece tartışmalı bir durum, alana yeniden istek göndermeden çözülebilir. Bu tür teknik izin saklama süresini müşteri belirler.

Veri minimizasyonu ve onaylar

Form ve veri alışverişi, belirtilen amaç için minimum veri setini toplamalıdır. Her ek alan, denetim hacmini, hata sayısını ve hukuki yükü artırır. W3C WAI, yalnızca süreci tamamlamak için gereken bilgilerin sorulmasını ve anlaşılır etiketler, talimatlar ve hata mesajları sağlanmasını önerir.

Basit bir alan filtresi kullanıyoruz:

1. Alan etkinlikte veya CRM'de hangi görevi çözüyor?
2. Değerin sahibi kim?
3. Alındıktan sonra hangi işlem yapılacak?
4. Kayıt sırasında zaten kesinlik gerekli mi?
5. Değer daha sonra ana sistemden (master system) alınabilir mi?
6. Katılımcı alanı doldurmazsa ne olur?

İlk üç soruya yanıtı olmayan alan genellikle kaldırılır. Örneğin, ayrıntılı sektör profili program için faydalı olabilir, ancak kimse segmentasyonu kullanmıyorsa ve veriler katılımcının rotasını etkilemiyorsa toplanmamalıdır.

Onay ve diğer işleme dayanakları amaçlara göre tasarlanır. Avrupa Veri Koruma Kurulu (EDPB), Genel Veri Koruma Tüzüğü (GDPR) rehberinde belirli, bilgilendirilmiş ve açık bir onay ile bunun nasıl ve ne zaman alındığının kanıtlanabilmesini şart koşar. Bu belge Rusya'daki hukuki incelemenin yerini tutmaz, ancak faydalı bir ilke sunar: etkinliğe katılım ile sonraki pazarlama iletişimleri tek ve ayırt edilemez bir alanda gizlenmemelidir.

İşleme onaya dayanıyorsa, veri sözleşmesinde şunlar gerekebilir:

• amaç;
• metin sürümü;
• zaman;
• arayüz kaynağı;
• seçim sonucu;
• müşteri sisteminde değiştirme veya geri çekme yöntemi.

Google Customer Match bir başka sınırı gösterir. Reklam platformu şirketin kendi online ve offline verileriyle çalışır; Avrupa Ekonomik Alanı'ndaki kullanıcı verilerinin iş ortağı yüklemeleri için ise onay sinyalleri talep eder. Kayıt verilerinin operasyonel olarak CRM'e aktarılması, tek başına herhangi bir reklam etkinleştirmesine izin verildiği anlamına gelmez. Bu amacı, alanların kapsamını ve dayanağı müşteri ayrıca kararlaştırır.

Nasıl kopya kayıt oluşturmamalı?

Tekilleştirme, benzer bir kaydı bulmayı ve onunla ne yapılacağına dair ayrı bir kararı içerir. Kalıcı bir dış ID'nin tam eşleşmesi otomatik olarak işlenebilir. Ad, şirket, e-posta veya telefon üzerinden olası bir eşleşme kurallar, öncelikler ve bazen manuel kontrol gerektirir. Başlatmadan önce ekip, hangi özelliklerin kesin sayıldığını ve hangilerinin kaydı yalnızca incelemeye gönderdiğini belirler.

Salesforce, eşleşme kurallarını (matching rules) ve kopya işleme kurallarını (duplicate rules) birbirinden ayırır. İlki adayları bulur, ikincisi eylemi belirler: uyar, izin ver veya oluşturmayı engelle. Bu mantık belirli bir platformun dışında da faydalıdır.

İşleyiş sırası:

1. Biliniyorsa kaydı external_person_id ile bulun.
2. Müşteri politikası arama anahtarı olarak izin veriyorsa, tam normalize edilmiş e-postayı kontrol edin.
3. Diğer doğrulanmış tanımlayıcıları kontrol edin.
4. Daha zayıf özelliklerin birleşimine göre adaylar oluşturun.
5. Belirsiz sonuç durumunda otomatik olarak birleştirmeyin.
6. Yeni ana kaydı yalnızca kurallar geçildikten sonra oluşturun.
7. Geçmişi üzerine yazmadan yeni kaydı veya etkinliği onunla ilişkilendirin.

Normalizasyon, gönderen ve alıcı tarafında aynı şekilde yapılır. Telefon, üzerinde anlaşılan biçime getirilir. E-posta boşluklardan arındırılır ve kabul edilen büyük/küçük harf kuralına göre kontrol edilir. Şirket adı tek anahtar olarak kullanılmamalıdır: yazım varyantları ve şirketler grubu yapısı yanlış eşleşmelere yol açar.

Ayrı bir görev de idempotentlik, yani güvenli yeniden gönderimdir. Kayıttan sonra ağ kesilirse gönderen sonucu bilmeyebilir ve isteği tekrarlayabilir. Aynı registration_id, attendance_id veya activity_id ikinci bir nesne oluşturmak yerine mevcut nesneyi güncellemeli veya doğrulamalıdır.

En az dört durumu kontrol edin:

Tek bir ana kayıt, her şey için tek satır anlamına gelmez. Ana kayıt kişiye aittir. Kayıtlar, katılımlar ve etkinlikler onun etrafında ayrı bir geçmiş olarak kalır.

Gönderim, Kabul ve Hata Sahipleri

Entegrasyonun iki adlandırılmış sahibi olmalıdır: gönderen tarafında ve alıcı tarafında. Birincisi bütünlük, format ve yeniden teslimattan sorumludur. İkincisi CRM şeması, kabul kuralları, ilişkiler ve kaydın kontrol amaçlı okunmasından sorumludur. Bu ikili olmadan ekipler hatayı kimin düzelttiğini ve yeniden kabulü kimin onayladığını anlayamaz.

Görev dağılımı şu şekilde kayıt altına alınabilir:

record_id, zaman, şema sürümü, neden kodu ve yeniden işleme durumunu içeren bir hata günlüğü gereklidir. Günlükteki kişisel veriler gerekli minimuma indirilir. Ekip için genellikle teknik ID ve korumalı bir kayda bağlantı yeterlidir.

Biz Aventura olarak müşterinin CRM'ini kurmuyor ve CRM içindeki kuralları belirlemiyoruz. Etkinliğin veri kaynaklarını tanımlayabilir, ilgili ekiple aktarım formatını kararlaştırabilir ve mekân senaryosunun beklenen verileri ürettiğini doğrulayabiliriz. Kabul modeli ve erişim haklarından müşterinin CRM sahibi sorumludur.

Kayıt açılışına kadar olan yolu nasıl kontrol ederim?

Uçtan uca test, katılımcının eylemiyle başlar ve CRM'deki kaydın kontrol amaçlı okunmasıyla biter. Bu noktalar arasında ekip, kaynağı, veri aktarımını ve işlemeyi ayrı ayrı kontrol eder. Yazılım arayüzünün yanıtı veya klasörde bir dosyanın belirmesi yalnızca ara adımı doğrular. Kayıt, hedef sistemde anahtar alanlar, ilişkiler, sahip ve durum kontrol edildiğinde kabul edilmiş sayılır.

Gerçek kişilerin verilerini içermeyen ayrı bir test etkinliği ve sentetik kayıt seti hazırlayın. Ardından senaryoları sırayla uygulayın.

1. Normal kayıt. Formu doldurun, UTM bağlamını kaydedin ve registration ID'yi kontrol edin.
2. Bilinen kişi. Kaydı mevcut bir test ana kaydının person ID'siyle tekrarlayın.
3. Check-in. Test yaka kartını tarayın ve ayrı attendance ID'yi kontrol edin.
4. Oturum veya stand. event_id, eylem türü, occurred_at zamanı ve kaynak sistem source_system ile bir activity_id oluşturun.
5. Görüşme. Zamanı, sahibi, sonucu ve kişi ile şirketle ilişkileri iletin.
6. Yeniden teslimat. Aynı kayıt tanımlayıcısını bir kez daha gönderin ve kopya oluşturulmadığından emin olun.
7. Referans verisi hatası. Bilinmeyen bir durum iletin ve sistemin kaydı üzerinde anlaşılan kurala göre reddettiğini kontrol edin.
8. Eksik zorunlu alan. Hata nedeninin gönderici için anlaşılır olduğundan emin olun.
9. Kontrol amaçlı okuma. CRM kaydını okuyun ve değerleri, ilişkileri ve sahibi beklentiyle karşılaştırın.
10. Düzeltme. Orijinal ID ve geçmiş kaybolmadan düzeltme sonrası kaydı tekrarlayın.

Her kontrol için beklenen ve gerçekleşen sonucu kaydedin. Sapmanın bir sahibi, düzeltme süresi ve aynı senaryonun yeniden çalıştırılması olmalıdır.

Kayıt ve check-in yük testi komşu bir sorunu çözer: altyapı planlanan akışı kaldırabilecek mi ve bir arıza durumunda ne olacak. Senaryoları kayıt ve check-in yük provası makalesinde toplanmıştır. Burada kabul kriteri, tüm yol boyunca tek bir kaydın anlamı ve bütünlüğüyle sınırlıdır.

Testin ardından her iki taraf alan haritası, durum sözlüğü ve test sonuçlarının sürümünü imzalar. Bu belgelerden birinin değişmesi, etkilenen senaryoların yeniden kontrol edilmesini gerektirir.

Başlatmaya hazırlık kontrol listesi

Katılımcıların varlıkları, alanları ve kabul edilen kayıt kriterini aynı şekilde anlamasıyla yapı hazır hale gelir. Bu kontrol listesi, form açılmadan önce yapılacak son ortak oturumda kullanılabilir. Tüm alan haritasını tekrarlamaz; ekibin kopyaları ve tartışmalı durumları kontrol etmekte zorlanacağı kararları kayıt altına alır.

1. Etkinliğin sabit bir event_id'si, kayıt, katılım ve aktivitenin ise kendi tanımlayıcıları vardır.
2. Kişi, şirket, kayıt, katılım ve aktivite anlam bakımından birbirinden ayrılmıştır.
3. Durumların kodları, tanımları, sahipleri ve sözlük sürümü vardır.
4. Alan haritası tipleri, zorunluluğu, dönüşümleri, kampanyayı ve hataları kayıt altına alır.
5. Eşleşme arama, yeniden gönderme ve kopya işleme kuralları ayrıca kararlaştırılmıştır.
6. Gönderme, alma ve hata düzeltme sahipleri belirlenmiştir.
7. Uçtan uca test normal bir kaydı, bilinen bir kişiyi, kopyayı, hatayı ve kontrol okumasını içerir.
8. CRM sahibi, kayıt açılmadan önce ilişkileri ve şema sürümünü onaylamıştır.

Bu hazırlık, verilerle yapılacak sonraki çalışmaların yerini tutmaz. Olayların ticari sistemle genel bağlantısını event-led growth ve huni materyali ele alır. Etkinlik sonrası eylemlerin pazarlama ve satışa aktarılma sırası SLA follow-up makalesinde ele alınmıştır. Mevcut yapı, CRM'in doğru ilişkiler ve sahiple birlikte doğrulanabilir bir kaydı kabul ettiği anda sona erer.

Biz Aventura olarak etkinlik veri noktalarını tek bir teknik şartnamede toplayabilir, misafir yolculuğunu baştan sona geçebilir ve müşteri ekibiyle ortak bir test yapabiliriz. Proje görüşmesi ve ön tahmini fiyat teklifi isteyin. Toplantıda etkinlik veri kaynaklarını, işimizin kapsamını ve CRM tarafındaki kabul katılımcılarını belirleyeceğiz.

Kaynaklar

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match