หน้าช่วยเหลือ Customer Match ของ Google Ads ระบุคอลัมน์ IP Address และ Timestamp แล้ว ต้องเช็กอะไรบ้าง

หน้าวิธีใช้ของ Google Ads สำหรับการสร้างรายการ Customer Match ด้วยการอัปโหลดไฟล์ ตอนนี้ระบุหัวคอลัมน์ที่รับได้ไว้ 8 คอลัมน์ และสองคอลัมน์ในนั้นเป็นข้อมูลชนิดใหม่ คือ "User IP address" และ "User Interaction timestamp" หน้า Create a Customer Match list by uploading a data file ระบุว่า IP address ต้องส่งเป็นข้อความธรรมดาที่ไม่แฮช การจับคู่ด้วย IP ยังไม่รองรับผู้ใช้ปลายทางในเขตเศรษฐกิจยุโรป (EEA) สหราชอาณาจักร และสวิตเซอร์แลนด์ และถ้าอัปโหลด IP โดยไม่มี timestamp ระบบจะจับคู่กับผู้ใช้ "ล่าสุดที่ทราบ" (latest known) ของ IP นั้น สำหรับนักการตลาดในไทย ในทางเทคนิคใช้คอลัมน์นี้ได้แล้ว แต่ก่อนเพิ่มลงไฟล์ควรตอบคำถามเรื่องคุณภาพข้อมูลและความเป็นส่วนตัวให้ได้ก่อน

หน้าอัปโหลด Customer Match ของ Google ระบุอะไรบ้าง

หน้าวิธีใช้ Google Ads สำหรับการอัปโหลดไฟล์ Customer Match ระบุหัวคอลัมน์ดังนี้ Email, Phone, First Name, Last Name, Country, Zip, User IP address และ User Interaction timestamp หกคอลัมน์แรกคือข้อมูลติดต่อที่ Customer Match ใช้มาหลายปีแล้ว ส่วนสองคอลัมน์สุดท้ายคือส่วนที่เพิ่มเข้ามา

สำหรับคอลัมน์ IP หน้าดังกล่าวให้คำจำกัดความไว้บรรทัดเดียวว่า "The IP address of the customer's device is captured at the exact moment of interaction." หมายถึง IP address ของอุปกรณ์ลูกค้าที่บันทึกไว้ ณ ช่วงเวลาที่เกิดการโต้ตอบจริง รูปแบบข้อมูลคือข้อความ (string) ที่เป็นที่อยู่ IPv4 หรือ IPv6 กฎการจัดรูปแบบมีไม่มาก ให้ตัดช่องว่างหน้าและท้ายออกทั้งหมด ที่อยู่ IPv6 ไม่สนตัวพิมพ์เล็กหรือใหญ่ และที่ต่างจากฟิลด์ข้อมูลส่วนบุคคลอื่นทุกช่องในไฟล์ คือหน้าวิธีใช้บอกให้ส่งที่อยู่นี้ "as a plain, unhashed string (don't hash)" หรือส่งเป็นข้อความธรรมดา ห้ามแฮช

หน้าดังกล่าวยังกำหนดข้อจำกัดด้านพื้นที่ไว้ชัดเจนว่า "IP matching isn't supported for end users located in the EEA, UK, or Switzerland (CH)" ประเทศไทยไม่อยู่ในรายการนี้ และไม่มีตลาดใดในเอเชียแปซิฟิกอยู่ในรายการนี้เช่นกัน

คอลัมน์ timestamp ทำงานร่วมกับ IP address อย่างไร

Google นิยาม User Interaction timestamp ว่า "The time of the recorded interactions from the corresponding IP address" คือเวลาของการโต้ตอบที่บันทึกจาก IP address นั้น พูดอีกแบบคือ timestamp มีไว้ผูก IP กับช่วงเวลาหนึ่ง เพราะที่อยู่เดียวกันอาจเป็นของคนต่างกันในเวลาต่างกัน

หน้าวิธีใช้มีกฎสามข้อที่กำหนดความสัมพันธ์ของสองคอลัมน์นี้

• "Timestamps can't be sent without an accompanying IP address." ส่ง timestamp โดยไม่มี IP address ไม่ได้ เพราะ timestamp อย่างเดียวไม่มีอะไรให้ยึด
• "If an IP address is uploaded without a timestamp, the system defaults to the 'latest known' user of that IP." ถ้าอัปโหลด IP โดยไม่มี timestamp ระบบจะใช้ผู้ใช้ล่าสุดที่ทราบของ IP นั้นเป็นค่าเริ่มต้น ดังนั้น timestamp ไม่ใช่ข้อบังคับ แต่การไม่ใส่จะเปลี่ยนว่าแถวนั้นถูกจับคู่กับใคร
• หน้าวิธีใช้ระบุว่าผู้ลงโฆษณาส่ง IP address ได้ทั้งแบบมีและไม่มีข้อมูลส่วนบุคคล (PII) และส่ง PII ได้ทั้งแบบมีและไม่มี IP แต่ถ้าส่งเพียง timestamp อย่างเดียวโดยไม่มีทั้ง IP และ PII ระบบจะแจ้งข้อผิดพลาด

ข้อสุดท้ายสำคัญกว่าที่เห็น เพราะหมายความว่ารายการที่มีแต่ IP address โดยไม่มีอีเมลหรือเบอร์โทรเลย ทำได้ตามกฎที่ระบุไว้ ตามถ้อยคำของหน้านี้ แถว IP หนึ่งแถวยืนได้ด้วยตัวเองโดยไม่ต้องมีฟิลด์ข้อมูลติดต่อที่แฮชแล้วอยู่ข้าง ๆ

รูปแบบ timestamp ที่รองรับ

หน้าวิธีใช้ยกตัวอย่างรูปแบบ timestamp ไว้ 5 แบบ มีเพียงสองแบบแรกที่มีข้อมูลเขตเวลา หน้านี้ระบุว่าแบบแรกเป็น UTC และแบบที่สองเป็นรูปแบบที่มีค่าชดเชยเขตเวลา (offset) ส่วนอีกสามแบบ หน้าดังกล่าวไม่ได้บอกว่า Google จะถือว่าเป็นเขตเวลาใด เรื่องนี้ควรระวังถ้าข้อมูลของคุณมาจากระบบที่บันทึกเวลาตามเวลาท้องถิ่นกรุงเทพฯ

สรุปคอลัมน์ของ Customer Match

ตารางด้านล่างสรุปแต่ละคอลัมน์ที่รองรับ และวิธีเตรียมข้อมูลตามที่หน้าวิธีใช้ Google Ads ระบุไว้เท่านั้น

ตัวอย่าง timestamp ทั้งห้าแบบที่หน้าวิธีใช้ให้ไว้ ได้แก่ 2012-08-15T00:01:54Z, 2012-08-14T17:01:54-07:00, "Aug 14, 2012 17:01:54", 08/14/2012T5:01:54 PM และ 2012-08-14 5:01:54 PM

อะไรเปลี่ยนไปเมื่อเทียบกับไฟล์ Customer Match แบบเดิม

Customer Match ทำงานด้วยการจับคู่ข้อมูลติดต่อของลูกค้าที่แบรนด์เก็บเอง (first-party data) เข้ากับบัญชี Google มาโดยตลอด รูปแบบไฟล์จึงสะท้อนเรื่องนี้ คือมีอีเมล เบอร์โทรศัพท์ และชื่อคู่กับที่อยู่ ที่ปรับรูปแบบและแฮชแล้ว หน้าวิธีใช้ยังอธิบายเส้นทางนี้อยู่ โดยระบุว่าเมื่ออัปโหลดผ่านหน้าจอ Google Ads ข้อมูลส่วนตัวของลูกค้าในไฟล์จะถูกแฮชบนคอมพิวเตอร์ของคุณด้วยอัลกอริทึม SHA-256 และยังคงบอกไม่ให้แฮช Country และ Zip

คอลัมน์ IP ต่างจากรูปแบบเดิมสองเรื่อง เรื่องแรก มันไม่ใช่ข้อมูลติดต่อที่ลูกค้ากรอกเองในฟอร์ม แต่เป็นตัวระบุเครือข่ายที่เซิร์ฟเวอร์บันทึกไว้ตอนที่มีการเข้าชมหรือทำธุรกรรม เรื่องที่สอง มันถูกส่งขึ้นไปแบบไม่แฮช ในขณะที่ฟิลด์ระบุตัวตนอื่นทุกช่องในไฟล์ต้องแฮชก่อนอัปโหลดหรือแฮชในเบราว์เซอร์

คอลัมน์ IP เริ่มปรากฏเมื่อไร

หน้าของ Google ไม่มีวันที่แก้ไขกำกับไว้ จึงยังยืนยันไม่ได้ว่าสองคอลัมน์นี้ถูกเพิ่มเข้ามาครั้งแรกเมื่อใด สื่อสายอุตสาหกรรมหยิบเรื่องนี้ขึ้นมาในช่วงปลายเดือนกันยายน Search Engine Land รายงานเมื่อวันที่ 25 กันยายน 2569 ว่าหน้านี้มีคอลัมน์ดังกล่าวแล้ว และ PPC Land รายงานต่อเมื่อวันที่ 26 กันยายน 2569 โดยอ้างรายงานของ Search Engine Land PPC Land ตีความว่าส่งข้อมูล IP ได้ทั้งแบบมีและไม่มีข้อมูลติดต่อ ซึ่งตรงกับที่หน้าวิธีใช้ระบุไว้

บทวิเคราะห์: ทำไม "ผู้ใช้ล่าสุดที่ทราบ" คือจุดที่ต้องระวัง

ส่วนนี้เป็นบทวิเคราะห์ ไม่ใช่ข้อความจาก Google

IP address ไม่ใช่ตัวบุคคล อินเทอร์เน็ตบ้านหนึ่งสายถูกใช้ร่วมกันโดยทุกคนในบ้าน เครือข่ายสำนักงานให้พนักงานหลายร้อยคนออกอินเทอร์เน็ตผ่านที่อยู่สาธารณะเพียงหนึ่งหรือไม่กี่ที่อยู่ ผู้ให้บริการมือถือมักใช้ carrier-grade NAT (CGNAT) ที่ให้ผู้ใช้จำนวนมากใช้ที่อยู่ IPv4 สาธารณะเดียวกันในเวลาเดียวกัน และ IP ของผู้บริโภคส่วนใหญ่ถูกเปลี่ยนมือไปตามเวลา ที่อยู่ที่ลูกค้าใช้ในเดือนมีนาคม อาจเป็นของคนแปลกหน้าในเดือนกันยายน

กฎเรื่อง timestamp ของ Google ตอบปัญหานี้ได้ส่วนหนึ่ง คือผูก IP กับช่วงเวลาที่เกิดการโต้ตอบ แล้วการจับคู่ก็ดูได้ว่าใครถือที่อยู่นั้นอยู่ในตอนนั้น แต่หน้าวิธีใช้บอกว่าถ้าไม่มี timestamp ระบบจะใช้ผู้ใช้ "latest known" ของ IP นั้น สำหรับสายธุรกิจที่ใช้ IP คงที่อาจไม่มีปัญหา แต่สำหรับลูกค้ามือถือที่อยู่หลัง CGNAT ร่วมกับคนอื่น หรือบ้านที่ลูกกับพ่อแม่ใช้สายเดียวกัน ผู้ใช้ล่าสุดที่ทราบอาจไม่ใช่ลูกค้าของคุณเลย สรุปในทางปฏิบัติคือ แถว IP ที่ไม่มี timestamp เป็นสัญญาณที่อ่อนกว่าแถวที่มี timestamp และแถว IP ที่มาจากเครือข่ายที่ใช้ร่วมกันก็อ่อนลงไปอีก

หน้าวิธีใช้ไม่ได้บอกว่า Google จัดการอย่างไรเมื่อ IP เดียวตรงกับหลายบัญชี Google พร้อมกัน timestamp ย้อนหลังได้ไกลแค่ไหน หรือ timestamp จากระบบที่ไม่มีเขตเวลาจะถูกตีความอย่างไร ช่องว่างเหล่านี้มีอยู่จริง และผู้ลงโฆษณาไม่ควรเติมมันด้วยการเดา

บทวิเคราะห์: ทำไม IP address ถึงไม่ต้องแฮช

Google ไม่ได้ให้เหตุผลของคำสั่ง "don't hash" ไว้ในหน้านั้น คำอธิบายหนึ่งที่เป็นไปได้คือเรื่องเลขคณิต พื้นที่ที่อยู่ IPv4 ทั้งหมดมีราว 4.3 พันล้านที่อยู่ ซึ่งเล็กพอที่ใครก็ได้จะแฮชทุกที่อยู่ที่เป็นไปได้ล่วงหน้า แล้วย้อนหาค่า SHA-256 ด้วยการเปิดตาราง การแฮช IPv4 จึงแทบไม่ได้ปกป้องอะไรจริง และยังเพิ่มขั้นตอนปรับรูปแบบที่อาจผิดพลาดได้ นี่เป็นการอนุมานที่สมเหตุสมผล ไม่ใช่เหตุผลที่ Google ประกาศ และไม่ได้เปลี่ยนข้อเท็จจริงว่าไฟล์ตอนนี้มีตัวระบุเครือข่ายแบบดิบอยู่ด้วย

ผลในทางปฏิบัติตรงไปตรงมา ไฟล์ Customer Match ที่มีคอลัมน์ IP อ่อนไหวกว่าไฟล์ที่ไม่มี ควรดูแลเรื่องการจัดเก็บ การส่งต่อ และสิทธิ์การเข้าถึงให้สมกับความอ่อนไหวนั้น

สิ่งที่แหล่งข่าวไม่ได้บอก

การอ่านหน้าวิธีใช้อย่างเป็นธรรมต้องชัดเจนเรื่องสิ่งที่หน้านั้นไม่ได้พูดด้วย หน้าดังกล่าวไม่ได้ระบุว่า

• แถว IP ส่งผลต่ออัตราการจับคู่ (match rate) อย่างไร หรือรายการที่มีแต่ IP ควรคาดหวัง match rate เท่าไร
• ขนาดกลุ่มเป้าหมายขั้นต่ำสำหรับการแสดงโฆษณาเปลี่ยนไปหรือไม่ สำหรับรายการที่สร้างจากข้อมูล IP
• แถว IP ถูกประมวลผลแบบเดียวกับข้อมูลติดต่อที่แฮชแล้วในระบบจับคู่ของ Google หรือไม่
• คอลัมน์เหล่านี้ใช้ได้ผ่าน Google Ads API, Data Manager หรือ connector ของพาร์ตเนอร์ด้วยหรือไม่ นอกเหนือจากการอัปโหลดไฟล์
• ตัวอย่าง timestamp สามแบบที่ไม่มี offset ใช้เขตเวลาใด
• คอลัมน์ถูกเพิ่มเมื่อไร หรือกำลังทยอยเปิดให้ทีละบัญชีหรือไม่

ถ้าเรื่องใดในนี้สำคัญกับแผนของคุณ ให้ทดสอบในบัญชีของคุณเอง และถือผลที่ได้เป็นข้อมูลของคุณเอง ไม่ใช่ค่ามาตรฐานจาก Google

สิ่งที่ต้องเช็กก่อนเพิ่มคอลัมน์ IP

ถ้าคุณใช้ แคมเปญ Google Ads ที่มี Customer Match อยู่แล้ว คอลัมน์ใหม่เป็นทางเลือก ไม่ใช่ข้อบังคับ หน้าวิธีใช้ไม่ได้บอกว่ารายการเดิมต้องเปลี่ยน ก่อนเพิ่มข้อมูล IP ควรไล่เช็กตามลำดับนี้

• IP จะมาจากไหน แหล่งที่มีประโยชน์คือแหล่งที่บันทึก IP พร้อม timestamp ที่เชื่อถือได้ ณ ตอนที่ลูกค้าโต้ตอบจริง เช่น log ของเซิร์ฟเวอร์หรือ CDN สำหรับการซื้อ ฟอร์มที่เก็บ IP ของผู้ส่ง หรือ event ใน CRM ที่บันทึกฝั่งเซิร์ฟเวอร์ ส่วน IP ที่ดึงมาจากไฟล์ส่งออกของเครื่องมือวิเคราะห์โดยไม่มี timestamp เป็นข้อมูลที่อ่อนที่สุด เพราะการอัปโหลดจะถอยไปใช้การจับคู่แบบ latest known
• มี timestamp หรือไม่ เก็บเวลาที่เกิดการโต้ตอบไว้คู่กับ IP และเก็บในรูปแบบที่มีเขตเวลา สองรูปแบบในหน้าวิธีใช้ที่มีข้อมูลเขตเวลาคือรูปแบบ UTC ที่ลงท้ายด้วย Z และรูปแบบที่มี offset ชัดเจน สำหรับไทย หมายถึงแปลงเป็น UTC หรือเขียน offset +07:00 กำกับไว้
• ข้อมูลสะอาดหรือยัง ตัดช่องว่าง เก็บ IPv4 และ IPv6 เป็นข้อความธรรมดา และไม่แฮช ลบที่อยู่ภายในองค์กร IP ของสำนักงาน จุดออกของ VPN และทราฟฟิกบอทที่รู้จักออกก่อนอัปโหลด เพราะแถวเหล่านี้เพิ่มแต่สัญญาณรบกวน ไม่ได้เพิ่มลูกค้า
• ผู้ใช้ปลายทางเป็นใคร หน้าวิธีใช้บอกว่าการจับคู่ด้วย IP ไม่รองรับผู้ใช้ปลายทางใน EEA สหราชอาณาจักร และสวิตเซอร์แลนด์ ถ้าไฟล์ลูกค้าของคุณมีทั้งผู้ซื้อชาวไทยและผู้เข้าชมจากยุโรปปนกัน ให้แยกกลุ่มก่อนอัปโหลด อย่าหวังว่าระบบจะทิ้งแถวที่คุณไม่ควรส่งไปเอง
• ประกาศความเป็นส่วนตัวของคุณเขียนว่าอะไร Customer Match กำหนดให้ผู้ลงโฆษณาปฏิบัติตามนโยบาย Customer Match ของ Google อยู่แล้ว ซึ่งหน้าวิธีใช้อ้างถึง ให้ตรวจว่าประกาศความเป็นส่วนตัวแจ้งลูกค้าหรือไม่ว่าตัวระบุเครือข่ายอย่าง IP address อาจถูกแบ่งปันให้แพลตฟอร์มโฆษณาเพื่อจับคู่กลุ่มเป้าหมาย และด้วยฐานทางกฎหมายใด
• วัดผลแยกกัน ถ้าจะทดสอบข้อมูล IP ให้สร้างเป็นรายการแยก อย่ารวมเข้ากับรายการข้อมูลติดต่อที่มีอยู่ จะได้เปรียบเทียบขนาดและผลลัพธ์ได้ การเปรียบเทียบจะสะอาดก็ต่อเมื่อแยกสัญญาณใหม่ออกมาต่างหาก

คุณภาพของ timestamp ขึ้นอยู่กับระบบติดตามผลของคุณ ถ้า event บนเว็บไซต์และข้อมูลคอนเวอร์ชันวิ่งผ่าน GA4 และ server-side tagging การ ตรวจระบบ GA4 และการติดตามผล คือจุดที่เหมาะที่สุดในการยืนยันว่าระบบใดเก็บข้อมูล IP และเวลาที่คุณมีสิทธิ์ใช้จริง

ความหมายสำหรับนักการตลาดไทย

ประเทศไทยไม่อยู่ในรายชื่อพื้นที่ที่หน้าวิธีใช้บอกว่าไม่รองรับการจับคู่ด้วย IP ดังนั้นตามเงื่อนไขของหน้านี้ การจับคู่ Customer Match ด้วย IP เปิดให้ผู้ลงโฆษณาที่กำหนดเป้าหมายผู้ใช้ในไทยใช้ได้ นั่นคือฝั่งแพลตฟอร์ม ส่วนฝั่งกฎหมายเป็นอีกเรื่องหนึ่ง

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) ถือว่าตัวระบุออนไลน์เป็นข้อมูลส่วนบุคคลได้ในหลายบริบท และ IP address ที่ผูกกับการโต้ตอบของลูกค้าและ timestamp ก็เป็นบันทึกประเภทที่ระบุตัวบุคคลได้เมื่อนำไปรวมกับข้อมูลอื่น ข้อนี้ไม่ใช่ความเห็นทางกฎหมายสำหรับกรณีใดกรณีหนึ่ง แต่เป็นเหตุผลที่ควรตรวจประกาศความเป็นส่วนตัว และความยินยอมหรือฐานทางกฎหมายกับที่ปรึกษากฎหมาย ก่อนอัปโหลด IP address ไปยังแพลตฟอร์มโฆษณา ผู้ลงโฆษณาที่ใช้ความยินยอมที่เก็บตอนชำระเงินหรือตอนสมัครสมาชิกอยู่แล้ว ควรยืนยันว่าถ้อยคำครอบคลุมการแบ่งปันแบบนี้ด้วย ไม่ใช่แค่ Customer Match ที่ใช้อีเมล

ยังมีเรื่องคุณภาพข้อมูลอีกด้าน ถ้าทราฟฟิกส่วนใหญ่ของเว็บคุณมาจากเครือข่ายมือถือ ให้เช็กสัดส่วนนั้นใน analytics ของคุณก่อน เพราะที่อยู่มือถือที่ใช้ร่วมกันเป็นข้อจำกัดที่รู้กันดีของการระบุตัวตนด้วย IP ซึ่งทำให้คอลัมน์ timestamp ยิ่งสำคัญสำหรับใครก็ตามที่จะทดสอบเรื่องนี้

สำหรับแบรนด์ในไทยที่ใช้ Customer Match ทำรีมาร์เก็ตติ้งหรือรายการยกเว้นอยู่แล้ว ขั้นแรกที่สมเหตุสมผลคือตรวจว่าตัวเองถือข้อมูลอะไรอยู่ ไม่ใช่รีบอัปโหลด คอลัมน์นี้ยังอยู่ตรงนั้นในเดือนหน้า

คำถามที่พบบ่อย

อัปโหลดรายการ Customer Match ที่มีแต่ IP address ได้ไหม

ได้ หน้าวิธีใช้ Google Ads ระบุว่าส่ง IP address ได้ทั้งแบบมีและไม่มีข้อมูล PII และระบุด้วยว่าแถวที่มีแต่ timestamp โดยไม่มี IP address หรือ PII จะทำให้เกิดข้อผิดพลาด หน้านี้ไม่ได้บอกว่ารายการที่มีแต่ IP ควรคาดหวัง match rate เท่าไร

ต้องแฮช IP address ก่อนอัปโหลดไหม

ไม่ต้อง หน้าของ Google บอกให้ส่ง IP เป็นข้อความธรรมดาที่ไม่แฮช ให้ตัดช่องว่างหน้าและท้ายออกก่อน ที่อยู่ IPv6 ใช้ตัวพิมพ์ใหญ่หรือเล็กก็ได้ ส่วนฟิลด์อีเมล เบอร์โทร และชื่อ ยังต้องปรับรูปแบบและแฮชด้วย SHA-256 หรือให้แฮชในเบราว์เซอร์ตอนอัปโหลด

การจับคู่ด้วย IP ใช้กับกลุ่มเป้าหมายในไทยได้หรือไม่

หน้าวิธีใช้ไม่ได้ยกเว้นประเทศไทย โดยระบุเพียงว่าไม่รองรับผู้ใช้ปลายทางใน EEA สหราชอาณาจักร และสวิตเซอร์แลนด์ หน้านี้ไม่ได้บอกว่าการเปิดใช้ต่างกันตามบัญชีหรือไม่ และผู้ลงโฆษณาในไทยควรยืนยันประกาศความเป็นส่วนตัวและฐานทางกฎหมายตาม PDPA กับที่ปรึกษากฎหมายก่อนอัปโหลดข้อมูล IP

ถ้าอัปโหลด IP address โดยไม่มี timestamp จะเกิดอะไรขึ้น

Google บอกว่าระบบจะใช้ผู้ใช้ "latest known" หรือผู้ใช้ล่าสุดที่ทราบของ IP นั้นเป็นค่าเริ่มต้น เนื่องจาก IP address ถูกใช้ร่วมกันและเปลี่ยนมือได้ ผู้ใช้คนนั้นอาจไม่ใช่ลูกค้าที่ทำการโต้ตอบจริง การใส่ timestamp ของการโต้ตอบจึงเป็นทางเลือกที่แข็งแรงกว่า

Google เพิ่มคอลัมน์ IP address และ timestamp เมื่อไร

ยังยืนยันไม่ได้ เพราะหน้าวิธีใช้ไม่มีวันที่แก้ไขกำกับไว้ Search Engine Land รายงานเรื่องคอลัมน์นี้เมื่อวันที่ 25 กันยายน 2569 และ PPC Land รายงานตามเมื่อวันที่ 26 กันยายน 2569 แต่ทั้งสองวันที่ไม่ได้ยืนยันว่าหน้านั้นเปลี่ยนเมื่อไร

สรุปสั้น ๆ

ตอนนี้ Customer Match รับ IP address แบบดิบและ timestamp ของการโต้ตอบได้ ควบคู่กับข้อมูลติดต่อที่แฮชตามปกติ แถวที่มีแต่ IP ทำได้ และยุโรปถูกยกเว้น คุณค่าของคอลัมน์ใหม่ขึ้นอยู่กับคุณภาพของ timestamp และความยินยอมที่อยู่เบื้องหลังข้อมูลเกือบทั้งหมด ถ้าต้องการให้ช่วยดูว่ารายการ Customer Match และข้อมูล first-party ป้อนเข้า บัญชี Google Ads ของคุณอย่างไร ทีม Relevant Audience ช่วยตรวจการตั้งค่าร่วมกับคุณได้ก่อนจะอัปโหลดอะไรขึ้นไป