แก้ GTM พร้อมกันหลายคนแล้วทับงานกันเอง วางลำดับการแก้ยังไงไม่ให้พัง

ลองนึกถึงบ่ายวันศุกร์ 16:40 ที่บีมแก้ trigger ของแท็ก Meta CAPI เสร็จใน Default Workspace แล้วกด Submit ตั้งชื่อเวอร์ชันว่า ‘fix’ แล้ว Publish ผ่านภายในสิบวินาที สิ่งที่เขาไม่รู้คือตอนเที่ยง นกสร้างแท็ก TikTok pixel ไว้ใน workspace เดียวกัน ยังไม่ทันใส่ Pixel ID แล้วไปกินข้าว

เวอร์ชัน ‘fix’ จึงพาแท็ก TikTok ที่ไม่มี ID ขึ้นไลฟ์ไปด้วย เช้าวันจันทร์ TikTok Events Manager ขึ้นแถบแดง ข้อมูลสองวันหาย และทั้งสองคนยืนยันได้ว่าตัวเองไม่ได้ทำอะไรผิด เพราะ GTM ทำงานตามที่มันถูกออกแบบ

เรื่องสุขภาพของ container โดยรวมมีเขียนไว้แล้วใน การตรวจ GTM container health ส่วนที่ยังขาดคือเมื่อคนหลายคนแตะ container เดียวกันในเวลาใกล้กัน ควรเรียงลำดับกันอย่างไร

Publish ใน GTM ปล่อยอะไรขึ้นไลฟ์จริง ๆ

workspace ใน GTM คือที่พักของการเปลี่ยนแปลงที่ยังไม่เป็นเวอร์ชัน เมื่อกด Submit ระบบสร้างเวอร์ชันจากทุกอย่างที่อยู่ใน workspace นั้นทั้งก้อน แล้ว Publish จึงส่งเวอร์ชันนั้นขึ้นไลฟ์ GTM ไม่มีตัวเลือกให้ติ๊กเฉพาะแท็กที่อยากปล่อย

container ฟรีมี workspace ได้สามอัน รวม Default Workspace ด้วย ทีมสี่คนจึงมีที่ไม่พอให้ทุกคนแยกกันคนละอัน ข้อนี้ทำให้ต้องมีกติกาจองที่ตามมา

การชนกันมีสามแบบ และ GTM เตือนไม่เหมือนกัน

หนึ่งงานหนึ่ง workspace และชื่อที่บอกว่าใครถืออยู่

ผมใช้ชื่อรูปแบบ วันที่-ชื่อคน-งาน เช่น 0611-นก-tiktok-pixel พอเปิดรายการ workspace ก็รู้ทันทีว่าอันไหนของใคร เก่าแค่ไหน และปล่อยได้หรือยัง เพราะมีแค่สามช่อง ผมแปะข้อความปักหมุดในกลุ่มทีมว่าตอนนี้ช่องไหนว่าง คนที่จะเริ่มงานใหม่ต้องมีช่องก่อน

1. ก่อนเปิดงานให้เปิดรายการ workspace ดูว่ามีงานใครค้างอยู่ แล้วประกาศในกลุ่มว่าจะแตะอะไร
2. สร้าง workspace ใหม่ตั้งชื่อตามรูปแบบข้างต้น ห้ามทำงานใหม่ใน Default Workspace
3. ถ้ามีแถบเตือนว่าไม่ทันเวอร์ชันล่าสุด กด Update workspace ก่อนแก้อะไรทั้งนั้น
4. แก้เฉพาะเรื่องของงานนั้น เจอเรื่องอื่นที่ต้องแก้ ให้จดไว้ไปทำใน workspace ถัดไป
5. เปิด Preview ใน Tag Assistant บนหน้าจริง ดูว่าแท็กที่ไม่เกี่ยวกับงานไม่ได้เปลี่ยนพฤติกรรม ขั้นตอนทดสอบอยู่ใน บทความ debug ด้วย GTM Preview
6. เปิดแท็บ Workspace changes แล้วเช็คว่ารายการที่เปลี่ยนตรงกับที่ตั้งใจแก้ทุกบรรทัด ถ้ามีรายการแปลกปลอม ให้หาเจ้าของก่อนกด Submit

เมื่อ GTM ขึ้นหน้าเทียบ conflict ควรเลือกฝั่งไหน

หน้า conflict แสดงรายการที่ถูกแก้ทั้งใน workspace ของคุณและในเวอร์ชันล่าสุด แล้วให้เลือกเก็บฝั่งใดฝั่งหนึ่งทีละรายการ นิสัยที่อันตรายที่สุดคือกดเก็บของตัวเองทั้งหมดเพราะอยากให้งานเสร็จ ซึ่งเท่ากับลบงานของคนที่ปล่อยไปก่อนโดยไม่ถามเขา ให้เปิด Version notes ของเวอร์ชันล่าสุดดูว่าใครปล่อยและเพราะอะไร แล้วคุยกันในแชทกลุ่ม

ตัวอย่างบทสนทนาที่ผมอยากเห็นก่อนกด resolve:

บีม: พี่นก ผม Update workspace แล้วมี conflict ที่ตัวแปร lineButtonSelector ครับ ผมเก็บของผมได้ไหม

นก: รอก่อน ฉันเปลี่ยน selector เป็น data-cta ตั้งแต่เมื่อวาน ถ้าเอาของเก่ากลับมาปุ่ม LINE บนหน้าสินค้าจะไม่ยิง ใช้ของล่าสุดนะ แล้วเธอต่อ trigger ของเธอจากอันนั้น

หลังเลือกครบ ให้เปิด Preview ซ้ำอีกรอบเพราะผลการรวมไม่ได้ผ่านการทดสอบมาก่อน

ใครมีสิทธิ์ Publish และจังหวะไหนไม่ควรกด

สิทธิ์ใน GTM มีระดับ Read, Edit, Approve และ Publish ผมให้คนซื้อสื่อมีระดับ Edit และให้คนหนึ่งหรือสองคนในทีมเป็นผู้ถือ Publish เท่านั้น ข้อดีอยู่ที่คนที่ต้องกด Publish มีเหตุผลต้องอ่านรายการเปลี่ยนแปลงก่อน นั่นคือด่านตรวจที่ไม่ต้องเขียนกฎเพิ่มสักข้อ

• ไม่ปล่อยบ่ายวันศุกร์หรือก่อนวันหยุดยาว เพราะถ้าพังจะไม่มีใครเห็นจนวันทำงานถัดไป
• ไม่ปล่อยตอนที่แคมเปญใหญ่กำลังเดินเพิ่มงบ ยกเว้นเป็นการแก้ปัญหาที่ทำให้ข้อมูลหาย
• ตั้งชื่อเวอร์ชันและโน้ตทุกครั้งโดยระบุว่าเปลี่ยนอะไร ทดสอบที่ไหน ใครขอ ชื่อ ‘fix’ กับ ‘test’ ห้ามใช้
• หลังปล่อย เปิด Realtime ของ GA4 และ Events Manager ของแพลตฟอร์มโฆษณาสิบห้านาที ดูว่า event ยังเข้าเท่าเดิม

ย้อนเวอร์ชันเมื่อพลาด และตรวจย้อนหลังทุกเดือน

ถ้าปล่อยแล้วพัง การย้อนทำได้โดยเปิดแท็บ Versions เลือกเวอร์ชันก่อนหน้าที่รู้ว่าดี แล้วสั่ง Publish เวอร์ชันนั้นอีกครั้ง ก่อนงานใหญ่ ผมกด Export Container เก็บไฟล์ JSON ไว้ด้วยเป็นสำรองอีกชั้น

ต้นเดือนผมไล่อ่านรายการเวอร์ชันของเดือนก่อนทีละบรรทัด ดูว่าเวอร์ชันไหนชื่อ fix หรือ test หรือไม่มีโน้ต และถามคนที่ปล่อยว่าตอนนั้นเปลี่ยนอะไร ไม่ได้ตั้งใจจับผิด แต่เวอร์ชันที่ไม่มีใครอธิบายได้คือสัญญาณว่ากติกายังไม่ถูกใช้ ทีมที่ดูแลหลายลูกค้าควรอ่านเพิ่มที่ การจัดการ GTM หลายลูกค้า ส่วนเรื่องทดสอบก่อนส่งงานอยู่ใน QA conversion tracking สำหรับ agency

สรุป

กติกาที่เห็นผลเร็วที่สุดคือเลิกทำงานใหม่ใน Default Workspace และสงวนสิทธิ์ Publish ไว้กับคนที่อ่านรายการเปลี่ยนแปลงก่อนกดทุกครั้ง สองข้อนี้ไม่ต้องซื้ออะไรและเริ่มได้ในวันที่อ่านจบ

ถ้าวันนี้ในรายการเวอร์ชันมีเวอร์ชันที่ชื่อ fix เต็มไปหมด ให้เริ่มจากตรงนั้น เพราะมันบอกว่าที่ผ่านมาปล่อยกันแบบไหน

• Publish ปล่อยทั้ง workspace ไม่มีตัวเลือกปล่อยเฉพาะแท็ก
• หนึ่งงานต่อหนึ่ง workspace ตั้งชื่อด้วยวันที่ คน และงาน
• Update workspace ก่อนเริ่มและก่อน Submit ทุกครั้ง
• เปิดอ่าน Version notes ก่อนเลือกฝั่งในหน้า conflict
• คนซื้อสื่อมีสิทธิ์ Edit คนที่อ่านรายการเปลี่ยนแปลงถือ Publish

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