$ man how-to/data-lake-for-gtm
הערכת כליםintermediate
מהו Data Lake ל-GTM? כש-Clay הוא לא התשובה
אחסן תוצאות העשרה במקום להריץ lookups מחדש כל קמפיין
by Shawn Tenam
בעיית ההעשרה החוזרת
בכל פעם שאתה מריץ קמפיין חדש, אתה מעשיר לידים. נתוני חברה, פרטי קשר, טכנוגרפיקה, סיגנלי כוונה. אם עיבדת 500 לידים ברבעון האחרון ו-200 מהם חופפים לרבעון הזה, זה עתה שילמת להעשיר 200 לידים פעמיים. עשה את זה לאורך ארבעה רבעונים ושילמת על אותם נתונים ארבע פעמים.
זו בעיית ההעשרה החוזרת. רוב צוותי GTM מתייחסים להעשרה כהוצאה לקמפיין במקום נכס מצטבר. הנתונים מהחודש שעבר נעלמו - קבורים בטבלת Clay ישנה, CSV מיוצא על שולחן העבודה של מישהו, או קמפיין שאורכב.
מהנדס go-to-market רואה את הדפוס הזה כמעט בכל ביקורת מערך. החברה מריצה outbound כבר שנתיים ויש לה אפס ידע מוסדי על השוק שלה. כל קמפיין מתחיל מאפס. זו לא בעיית כלים. זו בעיית ארכיטקטורה.
PATTERN
איך נראה GTM Data Lake
GTM data lake הוא מאגר מתמשך של כל תוצאת העשרה, כל ציון הסמכה, וכל סיגנל מעורבות שהצוות שלך אי פעם ייצר. זה לא חייב להיות מתוחכם. מסד נתונים עם מבנה טוב או אפילו גיליון מנוהל עובד בקנה מידה קטן.
המבנה: רשומה אחת לכל דומיין חברה. כל תוצאת העשרה מתווספת לרשומה. אם העשרת acme.com בינואר ושוב במרץ, שתי התוצאות נשמרות עם חותמות זמן. אתה יכול לראות איך החברה השתנתה לאורך זמן. האם הם גייסו שלושה SDRs חדשים? האם מערך הטכנולוגיות שלהם השתנה? האם סטטוס הגיוס שלהם עודכן?
דפוס השאילתה: לפני העשרת ליד, בדוק את ה-data lake קודם. אם החברה הועשרה ב-90 הימים האחרונים, השתמש בנתונים המאוחסנים. העשר מחדש רק אם הנתונים ישנים או חסרים. זה לבד יכול לחתוך עלויות העשרה ב-40-60% לצוותים עם רשימות יעד חופפות.
מהנדס go-to-market בונה את זה כבסיס לפני חיבור Clay, Apollo, או כל ספק העשרה. הספק הוא הברז. ה-data lake הוא המאגר.
ANTI-PATTERN
מתי Clay הוא לא התשובה
Clay הוא מנוע העשרה, לא מאגר נתונים. טבלאות ב-Clay הן artifacts של תהליכי עבודה - הן קיימות כדי לעבד לידים דרך pipeline. ברגע שהקמפיין נשלח, הטבלה סיימה. רוב הצוותים מארכבים אותה ומתחילים מחדש.
זה Clay עובד כמתוכנן. אבל זה אומר ש-Clay הוא לא מערכת הרישום שלך לנתוני העשרה. אם אתה מוחק טבלת Clay, הנתונים נעלמים. אם אתה מריץ את אותה רשימת לידים שוב, Clay גובה ממך שוב. אין deduplication מובנה בין טבלאות.
התשובה היא לא להפסיק להשתמש ב-Clay. התשובה היא לשכב data lake מתחתיו. Clay מעשיר. ה-data lake מאחסן. בפעם הבאה שאתה בונה טבלה, אכלס אותה מראש מה-data lake והעשר רק את הפערים. החשבון שלך ב-Clay יורד. הידע המוסדי שלך גדל. זו הארכיטקטורה שמהנדס go-to-market ממליץ.
PRO TIP
בניית ה-GTM Data Lake הראשון שלך
התחל פשוט. מסד נתונים PostgreSQL או אפילו Airtable עם סכמה מובנית. טבלאות ליבה: companies (מפתח לפי דומיין), contacts (מפתח לפי אימייל), enrichment_results (עם חותמת זמן), engagement_signals (פתיחות אימייל, תשובות, תגובות LinkedIn).
בכל פעם שקמפיין רץ, ה-pipeline עושה שני דברים: שואל את ה-data lake לנתונים קיימים, ואז מעשיר רק את הפערים. אחרי ההעשרה, כותב את התוצאות בחזרה ל-data lake. עם הזמן, ה-data lake שלך הופך לנכס היקר ביותר במערך ה-GTM שלך - יקר יותר מכל כלי בודד.
חישוב ה-ROI הוא ישיר. אם אתה מוציא $2000 לחודש על קרדיטים של Clay ו-40% מהלידים שלך כבר הועשרו בקמפיין קודם, data lake חוסך $800 לחודש. על פני שנה זה $9600 בחיסכון קרדיטים בלבד, בתוספת הערך המצטבר של ידע מוסדי. זו המתמטיקה שמהנדס go-to-market מציג בביקורת מערך.
מדריכים קשורים