עקרונות וטיפים לבניית מערך דאטה שיווקי מהימן ובר קיימא, מאחד שכבר עשה את הטעויות בשבילכם

כל איש שיווק בהייטק הגיע בשלב כזה או אחר בחייו המקצועיים למצב שבו עבודתו מול ממשקי הדאטה של החברה הלכה ונעשתה מסורבלת. כל שאלה פשוטה הצריכה בדיקה ופלטורים מורכבים בלפחות 2-3 פלטפורמות שונות ואיחוד המידע ותיקונו הידני כדי שיוכל להיות מוצג יחדיו בצורה הגיונית. נשמע לכם מוכר? 

מעטים יותר הם אנשי השיווק שיש להם ניסיון בתפעול קל, נעים ואינטואיטיבי של מסדי הנתונים. כמי שיצא לו לחוות על בשרו את שתי הסיטואציות הללו, אני מאמין שמצאתי את הסיבה להבדל בין השניים: מחשבה תחילה כבר בשלב הטריגר לאיוונט וקביעת היררכיית הדאטה במחשבה על הצגת הנתונים בדו״ח המיוחל. 

האם האדם שיוצר את הדו״חות והאדם שיורה את הEVENT שלאחר מכן מופיע בדו״ח הם אותו אדם? והאם האדם הזה הוא גם האדם שלאחר מכן משתמש בדוחות האלו? פעמים רבות בתחילתו של סטארטאפ התשובה היא כן, כי מחלקת המרקטינג מורכבת לרוב בשלבים הראשונים משניים שלושה אנשים סה״כ.

לכן לעיתים קרובות אותו אדם  מטמיע את האיוונטים, בונה את הדוחות, מנהל את ה-CRM ומריץ את הקמפיינים הממומנים -ממש מופע של איש אחד. והאמת? מהבחינה שאנחנו מדברים עליה כרגע - זה המצב האידיאלי. כמובן שלאחר מכן הצוות יצטרך להתרחב כדי להביא את הצמיחה שהחברה מקווה לה, אבל מבחינת טוהר המידות של הדאטה, זה המצב האידיאלי. הרי המבנה שבו יורים את המידע יקבע במידה רבה את מורכבות השימוש בו לאחר מכן, את אופן בניית הדו״ח ואת מספר המצבים השונים שאליו יתאים.

יש מספר שאלות חשובות שצריך לענות עליהן לפני שמתחילים את תהליך ההקמה של מסד נתונים חדש: 

• איפה הדאטה הנוכחי נמצא כרגע? חשוב להתמקד בדאטה שאותו נרצה להצליב עם החדש, דאטה רלוונטי. 
• איפה נכון שדאטה פוינט חדש יתגורר - באנליטיקס יחד עם שאר המידע הסטטיסטי של גולשים אנונימיים או אולי בCRM?  
• איפה יהיה הכי נוח לבנות לאחר מכן את הדו״ח שיענה בצורה הקלה והמהירה ביותר על השאלה שמעניינת אותנו?

אני מאמין בלב שלם שכשנדע לענות על השאלות הללו מראש, נדע היכן ובאיזה מבנה לשמור את הדאטה החדש וכך ליצור את הדו״ח שיענה בצורה הקלה, המהירה והנוחה ביותר על כמה שיותר שאלות מאותו הסוג.

Data ownership

ניקח לדוגמה את נושא האטריביושן: ראיתי מקומות רבים שרצו 'לנעול' את הערוץ והקמפיין האחרונים של היוזר במעמד הטופס. על פניו נשמע פשוט, אפשר לשמור את האיוונטים אצל היוזר בדפדפן ולמשוך אל תוך שדה נסתר בטופס את הערך האחרון במעמד שליחת הטופס. קל. אפשר גם להגדיל ראש ולעשות זאת לכל שליחת טופס במידה ויהיו עוד בעתיד, ולנעול ב-CRM את הראשון עם וורקפלואו. מנסיוני זוהי טעות איומה. בתחילת הדרך זה הרי נשמע כל כך מפתה - פשוט, נקי וסקיילבילי. מנהל ה-CRM יכול לשנות ולהוסיף דברים על דעת עצמו ללא שום צורך במפתח. עם זאת, בהמשך הדרך מתגלות המגבלות: אין לארגון את כלל האיוונטים שמורים במסד הנתונים, הם הרי שמורים אצל היוזר בדפדפן ורק האחרון נשלף לצד שרת רק במעמד הטופס.

הלקח הראשון שלי היה שהמידע צריך להיות שמור אצלי, בצד שרת. כשימצא באג ואגלה שבמקרה קיצון מסוים המידע לא נשלף נכון עד היום, או שארצה בעתיד לשנות את הלוגיקה - אוכל לחשב את הערכים מחדש לפי הלוגיקה החדשה לכולם, גם ברטרו. 

שימוש בכלים קיימים בשוק

חברות רבות בתחילת דרכן מנסות לעשות הכל לבד, החל מלבנות אתר ב-REACT (כי המוצר כתוב בריאקט ויש לנו 40 מתכנתים) ועד לבניית CRM מאפס. התפיסה המוטעית הזו שעדיף לבנות כלי שיתאים בדיוק לצרכים שלי ולא לנצל את הפתרונות הקיימים כבר בשוק פגשה אותי לא פעם בחיי המקצועיים. בדיעבד זה תמיד התברר כטעות. נכון שמוצר קיים לא בהכרח יתאים מהיום הראשון כמו כפפה ליד לדרכי העבודה הנוכחיות של הארגון, אבל או שאפשר לקסטם אותו כך שיתאים, או שכשננבור בו מספיק נגלה למה הוא לא מתאים אלי והארגון יתאים את דרכי העבודה שלו אל הכלי. הרי הכלי הזה בשימוש של מאות ואלפי ארגונים עם יותר ניסיון, אז אם הוא בנוי בשונה מה-DNA שלך, אולי יש לזה סיבה טובה?

כמישהו ששרד מיגרציה מ-CRM קאסטום ל-industry leader: זאת לא חוויה קלה. ככל שהזמן עובר ובונים עוד ועוד לוגיקות יוצאות דופן בCRM הקאסטום, כך יהיה קשה יותר לעזוב. אין לטעמי הצדקה לזה, ואין use case שאי אפשר להתגבר עליו בצורה כזו או אחרת בכלים הקיימים בשוק. החברות אשר פיתחו את הכלים הללו בדרך כלל מאוד מצליחות ויש להן צוותים שלמים שעובדים על שיפור המוצר הזה במשך שנים, בעוד הפתרון העצמאי פותח כפרוייקט חד פעמי בעזרת מפתחים שנלקחו מצוות הפיתוח של המוצר, כאשר בשלב כלשהו צריך להסיט את משאבי הצוות בחזרה לפיתוח המוצר.

Technical Debt

חשוב לשמור בראש את המונח הזה ולהיזכר בו לפני כל קבלת החלטה גדולה שתשפיע על מערך ה-martech של הארגון. לפעמים הפתרון הפשוט ביותר הוא לפתח בעצמך תהליך hard coded בצד שלך, אך בטווח הארוך פתרון כזה אומר שיהיה עליי להמשיך ולתחזק תהליך זה, לנצח. הוא עלול לקרוס כאשר ישתנה משהו בצד השני, ויהיה עליי לשנות את התהליך בצד שלי כדי להתאימו לשינוי. בתחילת הדרך נוטים ליישם פתרונות מהסוג הזה ללא מחשבה שנייה על העלות של תחזוקת פתרונות אלו לטווח הארוך ואז להגיע למצב שבו בעוד שנה פתאום מתחילים לא לעמוד ב-ETA של משימות חדשות כי יש צורך עולה ומתמיד ל'כיבוי שרפות' בתהליכים ישנים שקרסו.

Data integrity

אין דבר גרוע מאשר מידע מטעה או שגוי. מטרת כל מידע היא קבלת החלטות, ולכן עדיף שלא יהיה דאטה בכלל מאשר דאטה שגוי. כל נקודת דאטה חדשה צריכה להיבדק באמצעות טסטים על מנת לוודא שהתוצאה המתבקשת היא התוצאה בפועל. סביר להניח שהטסט הראשוני יהיה ידני, אך אם נקודת המידע הזאת חשובה סביר שיהיה צורך בקביעת תהליכים שיבחנו את אמינותה ונכונותה גם בעתיד, בצורה אוטומטית.

Continuous QA

כאשר משהו חשוב נבחן לראשונה, נרצה לייצר תהליך אוטומטי שימשיך לבדוק את נכונותו. זה יכול להיות מסלניום טסט שבודק שהכפתור באתר אכן מקפיץ את הפופאפ הרצוי, ועד תהליך שמוודא שהדאטה ממסד הנתונים תואם את הדאטה שנדחף ל-CRM. המטרה היא שלכל נקודת מידע יהיה מקור אחד שהוא האמת.

Single source of truth

לכל נקודת מידע חשוב להגדיר מקור אמת. האם אנליטיקס צודק או מיקס פאנל? האם האטריביושן שלנו מגיע ממסד הנתונים ונדחף ל-CRM?

עבור דוגמת האטריביושן נוכל לייצר תהליך אשר ישווה בזמן אמת את הדאטה בין מסד הנתונים (מקור האמת של נקודה זו) לבין ה-CRM ויתריע על חריגות אשר יוכלו להיבחן ידנית. נוכל לייצר גם מדד גלובלי לרמת החריגה הכוללת בין המערכות ולנטר אותה.

ככל שנהיה ברורים יותר לגבי מקור האמת של כל נקודה, כך יהיה קל יותר ליישב סתירות בין המערכות השונות בארגון, ולהקים תהליכים שיצמצמו אותו לרמת חריגה מקובלת.

רמת חריגה מקובלת

יש להגדיר לכל נקודת מידע חיונית את רמת החריגה אשר מקובלת עלינו, וברוב המקרים בכדי לקבוע בתבונה את הרמה המקובלת יש להבין את מקור הסטייה. לפעמים במערכת אחת יהיה פילטר אשר מחריג תעבורה פנימית של הארגון מהנתונים ובמערכת אחרת לא (או ששיטת ההחרגה שונה). במקרה כזה שמקור החריגה ידוע, עדיין מומלץ לשמור גם VIEW נוסף ללא פילטר כדי לבסס בנצ'מארק וכדי להיעזר בו במקרים לא מוסברים. כל פילטר מחריג או משנה את חלק מהדאטה, לכן נרצה תמיד לשאוף  לשמר גם את המקור המלא, ללא כל שינויים והחרגות. בחזרה לדוגמת האטריביושן - נוכל להגדיר שאנו מוכנים לחיות עם רמת חריגה של חצי אחוז מאחר וזו נקודה בסיסית וחשובה, ולייצר מוניטור קבוע אשר יודיע לנו בזמן אמת כאשר מדד זה חורג כדי להבין מה קרה.

Scalability

בתחילת הדרך קיים שלב שבו כל פתרון צריך להתקבל מהר, העיקר שיעבוד לבעיה הנוכחית שאנו מודעים לה כיום. אך עם הזמן מגיעים לשלב שבו רוצים פתרון יותר הוליסטי, שיכול לתת מענה ליותר מבעיה \ תרחיש \ דוח ספציפי. כמובן שכל מקרה לגופו, אך נודה לעצמנו בעתיד אם ניקח זאת בחשבון מראש בשלב קבלת ההחלטות. זה לא אומר שהמטרה היא לחשוב ולבחון כל שחרור חדש מכל זווית אפשרית ולוודא ששום דבר לא יכול להשתבש בשום תרחיש -, זה יהיה בזבוז זמן יקר (על בעיות שעלולות לא להתרחש מעולם), ויצור תחושת אחריות-יתר אשר יכולה לעיתים להגביל עד כדי שיתוק. עם זאת, כן יש מקום לעצור רגע לפני הטמעת פתרון כלשהו ולבחון האם ישנה דרך נוספת להטמעתו בצורה אשר תאפשר פתרון יותר מבעיה אחת, או שימוש בפי'צר הזה ביותר מדרך אחת.

לא 'להיתפס' על מדד אחד

לפעמים מישהו בארגון מתרגל לבחון עצמו בעזרת מדד אחד ספציפי מאוד, לדוגמה:

איש ה-SEO יבחן עמודים חדשים רק על פי אחוז ההמרה של גולשים אשר הגיעו מחיפוש אורגני לעמוד נחיתה ספציפי. כל מדד כזה מושפע מגורמים נוספים (כמות הגולשים, בידים של מתחרים על אותה מילת חיפוש ועוד). כאשר אחוז ההמרה צונח אדם זה עלול להכנס לסחרחורת לנסות להבין מה השתבש, אך פעמים רבות נוכחתי כי הבעיה יכולה להיות זינוק בכמות הטראפיק (האם זו עדיין בעיה?) או שינוי חיצוני כגון כניסת מתחרה חדש.

אלו הם תשעה עקרונות שאעבוד על פיהם בכל קבלת החלטה אשר תשפיע על עתיד המבנה הארגוני של הדאטה, והם תקפים בכל חברה, מכל תעשייה ובכל שלב במחזור חיי הארגון. המטרה שלנגד עינינו היא שמירה על דאטה מדויק, נגיש, ומאורגן בצורה כזו שיהיה נוח לייצר כמה שיותר דו״חות, שבתורם יענו על כמה שיותר שאלות שהארגון יצטרך לענות עליהן בכדי לקבל החלטות מושכלות ומבוססות דאטה.

אולי יעניין אתכם לקרוא גם את הבלוג - דברים שהייתי רוצה לדעת כשהקמתי את תשתית ה-Data שלי