Enhanced Conversions ל-Google Ads

הפער שגוגל צריך לסגור

גוגל מייחסת המרה למודעה דרך GCLID, מזהה הקליק שנשמר בקוקי. כשהקוקי חסום, נמחק, או המשתמש המיר במכשיר אחר, ההמרה קורית אבל לא מיוחסת לאף מודעה. Enhanced Conversions סוגר חלק מהפער: באתר נאסף מידע מזהה של הלקוח (בעיקר אימייל), הוא מגובב ב-SHA-256, וגוגל מתאימה אותו לחשבון גוגל מחובר.

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

אותה מטרה, שחזור המרות שאבדו, אבל שתי ארכיטקטורות שונות: מטא מוסיפה ערוץ שרת ומאחדת לפי event_id, וגוגל מוסיפה שכבת התאמה מגובבת.

לפני שמתחילים

1החלק בשרת: בניית google_user_data

אנחנו מזרימים את הנתונים בעמוד התודה, משום שזו הנקודה שבה כבר קיימים כל פרטי ההזמנה, והם זמינים לתגית ההמרה של Google Ads.

הכלל פשוט: מידע שמזהה אדם מגובב (hashed), ומידע שאינו מזהה (מיקוד, מדינה) נשלח כפי שהוא. הקוד מגבב בשרת, כך שמידע מזהה גולמי לא מגיע לדפדפן בשום שלב, וזה יתרון פרטיות אמיתי:

/**
 * Expose the order's first-party data (SHA-256, Hex) to the dataLayer
 * on the Order Received page, so Enhanced Conversions can match it.
 * Raw PII is hashed on the SERVER and never reaches the browser.
 */
add_action( 'woocommerce_thankyou', 'doffice_google_ec_user_data', 5, 1 );

function doffice_google_ec_user_data( $order_id ) {
    if ( ! $order_id ) {
        return;
    }
    $order = wc_get_order( $order_id );
    if ( ! $order ) {
        return;
    }

    // --- normalize FIRST, then hash (SHA-256, Hex) ---
    $email = strtolower( trim( (string) $order->get_billing_email() ) );
    $fname = strtolower( trim( (string) $order->get_billing_first_name() ) );
    $lname = strtolower( trim( (string) $order->get_billing_last_name() ) );
    // preg_replace below only STRIPS FORMATTING. It is NOT yet E.164.
    // Convert to true E.164 (e.g. +972...) before hashing, or leave it empty.
    $phone = preg_replace( '/\D/', '', (string) $order->get_billing_phone() );

    $user_data = array(
        'sha256_email_address' => $email ? hash( 'sha256', $email ) : '',
        'sha256_phone_number'  => $phone ? hash( 'sha256', $phone ) : '',
        'address' => array(
            'sha256_first_name' => $fname ? hash( 'sha256', $fname ) : '',
            'sha256_last_name'  => $lname ? hash( 'sha256', $lname ) : '',
            'postal_code'       => $order->get_billing_postcode(),
            'country'           => $order->get_billing_country(),
        ),
    );
    ?>
    <script>
      window.dataLayer = window.dataLayer || [];
      window.dataLayer.push({
        'event': 'ec_user_data',
        'google_user_data': <?php echo wp_json_encode( $user_data ); ?>
      });
    </script>
    <?php
}

2החלק ב-GTM: להפעיל Enhanced Conversions

ב-GTM מגדירים User-Provided Data variable בשיטת Code, שקורא את google_user_data מה-dataLayer, ומחברים אותו לתגית ההמרה. הצעדים:

1. ליצור Variable חדש ← User-Provided Data.
2. לבחור Source = Code.
3. להחזיר את google_user_data.
4. לפתוח את תגית Google Ads Conversion.
5. להפעיל Enhanced Conversions.
6. לבחור את המשתנה שיצרתם.

אם אתם עובדים עם gtag ישירות (בלי GTM), מגדירים את הנתונים לפני אירוע ההמרה:

<!-- If you use gtag.js directly (not GTM): set user_data BEFORE the -->
<!-- Google Ads conversion event fires, using the hashed values above.  -->
<script>
  gtag('set', 'user_data', {
    "sha256_email_address": dl.google_user_data.sha256_email_address,
    "sha256_phone_number":  dl.google_user_data.sha256_phone_number,
    "address": {
      "sha256_first_name": dl.google_user_data.address.sha256_first_name,
      "sha256_last_name":  dl.google_user_data.address.sha256_last_name,
      "postal_code":       dl.google_user_data.address.postal_code,
      "country":           dl.google_user_data.address.country
    }
  });
</script>

3לבדוק שזה עובד

ב-Google Ads יש דוח Diagnostics ל-Enhanced Conversions. הוא מראה אם הנתונים המגובבים מתקבלים בפורמט תקין, ומה שיעור ההתאמה. אם משהו שבור (פורמט לא תקין, שדה חסר), הוא יופיע כאן, לרוב בלי שום שגיאה גלויה באתר עצמו.

רוב האנשים לא יודעים איפה הדוח נמצא, זה הנתיב אליו. שימו לב: לפעמים עוברות כמה שעות עד שהנתונים הראשונים מופיעים בדוח, זה נורמלי.

גבולות ומלכודות

• נרמול לפני גיבוב. אימייל באותיות קטנות ובלי רווחים, טלפון ב-E.164. אחרת ההתאמה נשברת בשקט.
• צד הדפדפן נחסם. כמו כל סקריפט צד-שלישי, גם זה נחסם ב-25 עד 35 אחוז מהמקרים. הפתרון: להריץ דרך Server-Side GTM, שמסיר חלק גדול מנקודות הכשל.
• יעדים מיובאים מ-GA לא נתמכים. צריך פעולת המרה ייעודית של Google Ads.
• פרטיות. hash של אימייל הוא מידע מזוהה-למחצה (pseudonymized), עדיין מידע אישי לפי GDPR. לשלוח רק בהסכמה.

מטא מול גוגל: מבט משווה

שני הצדדים מגיעים לאותה מטרה, אבל לא באותה דרך. כך זה נראה זה לצד זה:

השורה התחתונה: במטא ה-event_id הוא הלב, כי הוא מונע ספירה כפולה בין שני ערוצים. בגוגל אין ספירה כפולה כי אין ערוץ שני, יש שכבת התאמה אחת שנשענת על מזהים מגובבים.

מה הלאה: צד Google Ads של הארכיטקטורה

עם המדריך הזה, מדידת ההמרות עומדת על שני הצדדים באותה איכות, מטא וגם גוגל:

לעסקים מבוססי-לידים, ההמשך הטבעי הוא Enhanced Conversions for Leads, שמחזירה עסקאות שנסגרו ב-CRM בחזרה לגוגל, בדיוק כמו המרות אופליין. זה סוגר את צד ה-Google Ads של המדידה, לא את כל הארכיטקטורה. עוד לפנינו שכבות: Server-Side GTM, Consent Mode, Measurement Protocol, וייחוס. אבל בשלב הזה, כל רכישה כבר נמדדת בשני הערוצים, ומיוחסת גם כשהקוקי נשבר.

מושגים שהוזכרו