ประเภทข้อมูลและประเภทความหมาย

เมื่อคุณสร้างปลั๊กอินจากชุมชนสำหรับใช้ลิงก์ข้อมูล แต่ละช่องที่คุณกำหนดในสคีมาจะต้องใช้ประเภทข้อมูล ประเภทข้อมูลจะกำหนดประเภทพื้นฐานของช่อง เช่น BOOLEAN, STRING, NUMBER เป็นต้น

นอกเหนือจากประเภทข้อมูลแล้ว Looker Studio ยังใช้ประเภทความหมายด้วย ประเภทความหมายช่วยอธิบายประเภทข้อมูลที่ข้อมูลนำเสนอ ตัวอย่างเช่น ช่องที่มีประเภทข้อมูล NUMBER อาจแสดงจํานวนเงินหรือเปอร์เซ็นต์ในเชิงความหมาย และช่องที่มีประเภทข้อมูล STRING อาจแสดงถึงเมืองในแง่ความหมาย หากต้องการดูประเภทความหมายที่ใช้ได้ โปรดดูเอกสารประกอบเกี่ยวกับประเภทความหมาย

ช่องสคีมาเครื่องมือเชื่อมต่อชุมชนและ Looker Studio

เมื่อคุณกำหนดสคีมาสำหรับปลั๊กอินจากชุมชนสำหรับใช้ลิงก์ข้อมูล จะมีพร็อพเพอร์ตี้หลายรายการสำหรับแต่ละช่องที่จะกำหนดวิธีการแสดงและใช้ช่องดังกล่าวใน Looker Studio เช่น

• ระบบจะกำหนด conceptType ในสคีมาเครื่องมือเชื่อมต่อของคุณโดยใช้พร็อพเพอร์ตี้ conceptType พร็อพเพอร์ตี้นี้จะกำหนดว่าช่องดังกล่าวเป็นมิติข้อมูลหรือเมตริก ดูคำอธิบายเกี่ยวกับความแตกต่างระหว่างเมตริกกับมิติข้อมูลได้ที่มิติข้อมูลและเมตริก
• คุณกำหนดประเภทความหมายได้ในสคีมาเครื่องมือเชื่อมต่อ หรือให้ Looker Studio ตรวจพบได้โดยอัตโนมัติโดยอิงตามพร็อพเพอร์ตี้ประเภทข้อมูลที่กำหนดไว้ในเครื่องมือเชื่อมต่อและค่าข้อมูลที่เครื่องมือเชื่อมต่อแสดงผล ดูรายละเอียดเกี่ยวกับวิธีการทำงานนี้ได้ที่การตรวจหาประเภทความหมายอัตโนมัติ
• ประเภทการรวมจะกำหนดว่าค่าเมตริก (มิติข้อมูลจะถูกละเว้น) จะรวบรวมอีกครั้งได้หรือไม่ การตั้งค่าพร็อพเพอร์ตี้ semantics.isReaggregatable เป็น true จะมีค่าเริ่มต้นเป็นการรวม SUM มิเช่นนั้นระบบจะตั้งค่าเป็น Auto นอกจากนี้คุณยังตั้งค่าประเภทการรวมเริ่มต้นด้วยตนเองสำหรับช่องที่รวบรวมข้อมูลอีกครั้งได้ โดยใช้พร็อพเพอร์ตี้ defaultAggregationType

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

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

การตั้งค่าข้อมูลเชิงความหมาย

การตั้งค่าข้อมูลเชิงความหมายมี 2 วิธี โดยจะตั้งค่าความหมายของฟิลด์ด้วยตนเองหรือจะใช้ Looker Studio เพื่อตรวจหาโดยอัตโนมัติก็ได้

ตัวอย่างเช่น หากคุณมีตัวเลขที่แสดงถึงสัญลักษณ์ดอลลาร์สหรัฐ Looker Studio จะไม่สามารถตรวจหาประเภทความหมายนี้โดยอัตโนมัติ นอกจากนี้ การตรวจหาความหมายอัตโนมัติยังต้องใช้ Looker Studio ในการเรียกใช้การดึงข้อมูลสําหรับแต่ละช่องของสคีมาด้วย หากคุณระบุสคีมาด้วยตนเอง ก็จะไม่มีการเรียกการดึงข้อมูล ในกรณีที่คุณทราบประเภทความหมาย (เช่น สกุลเงิน เปอร์เซ็นต์ วันที่ ฯลฯ) ของข้อมูล เราขอแนะนำให้ตั้งค่านี้ในสคีมาอย่างชัดเจนเพื่อเหตุผลด้านความถูกต้องและด้านประสิทธิภาพ

การตั้งค่าประเภทความหมายด้วยตนเอง (แนะนำ)

หากคุณทราบประเภทความหมาย คุณจะกำหนด semantics ด้วยตนเองสำหรับช่องสคีมาแต่ละช่องได้ ดูรายละเอียดทั้งหมดเกี่ยวกับพร็อพเพอร์ตี้ที่ใช้ได้ในหน้าข้อมูลอ้างอิงช่อง หากเลือกกำหนดประเภทความหมายด้วยตนเอง เราขอแนะนำให้กำหนด semanticType และ semanticGroup สำหรับทุกช่อง การระบุพร็อพเพอร์ตี้เหล่านี้ด้วยตนเองจะทำให้กระบวนการตรวจหาประเภทความหมายอัตโนมัติไม่ทำงาน หากคุณตั้งค่าช่องบางช่องด้วยตนเอง แต่ไม่ใช่ทั้งหมด ช่องที่คุณไม่ได้กำหนดค่าเริ่มต้นเป็น Text, Number หรือ Boolean ขึ้นอยู่กับ dataType ที่ระบุสำหรับช่อง

ต่อไปนี้เป็นตัวอย่างสคีมาแบบง่ายๆ ที่ตั้งค่าประเภทความหมายด้วยตนเอง ตั้งค่า Income เป็นสกุลเงิน และตั้งค่า Filing Year เป็นวันที่

data-studio/semantics.gs

ดูใน GitHub

var schema = [
  {
    'name': 'Income',
    'label': 'Income (in USD)',
    'dataType': 'NUMBER',
    'semantics': {
      'conceptType': 'METRIC',
      'semanticGroup': 'CURRENCY',
      'semanticType': 'CURRENCY_USD'
    }
  }, {
    'name': 'Filing Year',
    'label': 'Year in which you filed the taxes.',
    'dataType': 'STRING',
    'semantics': {
      'conceptType': 'METRIC',
      'semanticGroup': 'DATE_OR_TIME',
      'semanticType': 'YEAR'
    }
  }
];

การแก้ปัญหาประเภทความหมายที่กำหนดเอง

หากคุณตั้งค่าประเภทความหมายไม่ถูกต้องสำหรับข้อมูลที่สำคัญ ข้อมูลนั้นจะทำงานได้ไม่ถูกต้อง อาจทดสอบได้ยาก แต่ก็มี 2-3 สิ่งที่คุณทำได้เพื่อช่วยค้นหาปัญหา

1. แสดงผล 2 หรือ 3 แถวจากข้อมูล ไม่ใช่ข้อมูลทั้งหมด จากนั้นให้ตรวจสอบด้วยตนเอง
2. สร้างตารางใน Looker Studio ซึ่งใช้เฉพาะช่องที่คุณพยายามตรวจสอบ
3. ให้ความสำคัญกับช่อง Geo และ Date มากเนื่องจากมีรูปแบบที่เข้มงวดที่สุด

การตรวจหาประเภทความหมายอัตโนมัติ

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

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

ขั้นตอนของกระบวนการตรวจหาอัตโนมัติมีดังนี้

1. ขอสคีมาโดยการเรียกใช้ฟังก์ชัน getSchema ของเครื่องมือเชื่อมต่อชุมชน
2. ทำซ้ำผ่านกลุ่มช่องที่กำหนดไว้ในสคีมาเครื่องมือเชื่อมต่อและปัญหา getData ขอช่องดังกล่าว คำขอ getData จะดำเนินการด้วยพารามิเตอร์ sampleExtraction ที่ตั้งค่าเป็น true เพื่อระบุว่าคำขอข้อมูลมีไว้เพื่อวัตถุประสงค์ในการตรวจหาความหมาย
3. ระบุประเภทความหมายของช่องนี้ตามประเภทข้อมูลของช่องและรูปแบบของค่าที่แสดงผลจากคำขอ getData

ข้อควรระวัง: การตรวจหาประเภทความหมายอัตโนมัติไม่สามารถระบุประเภทความหมายทั้งหมดสำหรับสคีมาได้อย่างถูกต้อง แต่จะตรวจจับได้เฉพาะประเภทเวลา/วันที่และประเภทความหมายทางภูมิศาสตร์

ตัวเลือกสำหรับการจัดการการตรวจหาประเภทความหมายอัตโนมัติ

เมื่อ Looker Studio เรียกใช้ฟังก์ชัน getData ของปลั๊กอินจากชุมชนสำหรับใช้ลิงก์ข้อมูล เพื่อวัตถุประสงค์ในการตรวจหาความหมาย คำขอที่เข้ามาจะมีพร็อพเพอร์ตี้ sampleExtraction ซึ่งจะตั้งค่าเป็น true Looker Studio จะใช้ข้อมูลที่เครื่องมือเชื่อมต่อแสดงผลเพื่อระบุประเภทเชิงความหมายของช่องดังกล่าวเท่านั้น เนื่องจากจะไม่มีการใช้ค่านี้เพื่อจุดประสงค์อื่นใด จึงไม่จำเป็นต้องใช้ข้อมูลจริงจากแหล่งที่มาภายนอกของคุณ

มีหลายวิธีในการปรับปรุงการตรวจหาประเภทความหมายในโค้ดของคุณ:

• แนะนำ: ส่งผ่านค่าที่กำหนดไว้ล่วงหน้า
  แสดงผลค่าที่กำหนดไว้ล่วงหน้าสำหรับแต่ละช่องที่สื่อถึงประเภทความหมายสำหรับช่องได้ดีที่สุดและ Looker Studio ทราบว่าตรวจพบได้อย่างถูกต้อง เช่น หากประเภทเชิงความหมายสำหรับช่องคือประเทศ ให้แสดงผลค่าอย่าง IT สำหรับอิตาลี ประโยชน์อีกข้อของวิธีนี้คือ เป็นวิธีที่รวดเร็วกว่ามาก เนื่องจากคุณไม่จำเป็นต้องส่งคำขอ HTTP ไปยังบริการของบุคคลที่สามเพื่อขอข้อมูล

• ส่งคืนเฉพาะระเบียน n จำนวน
  หากบริการของบุคคลที่สามที่คุณดึงข้อมูลมารองรับจำนวนแถวที่จำกัดเมื่อขอข้อมูล จะส่งชุดย่อยของแถวขนาดเล็กไปยัง Looker Studio แทนชุดข้อมูลทั้งหมด การดำเนินการนี้จะจำกัดปริมาณข้อมูลที่คุณต้องส่งไปยัง Looker Studio สำหรับคำขอตรวจจับความหมายแต่ละรายการ

• ขอคอลัมน์ทั้งหมดและแคชการตอบกลับ
  หากสามารถขอคอลัมน์ทั้งหมดสำหรับบริการของบุคคลที่สามที่ใช้ดึงข้อมูลอยู่ได้ ให้ดึงข้อมูลคอลัมน์ทั้งหมดและแคชผลลัพธ์ในคำขอตรวจจับความหมายแรกที่ได้รับจาก Looker Studio สำหรับคำขอตรวจจับความหมายที่ตามมา จะดึงค่าคอลัมน์จากแคชแทนการส่งคำขอ HTTP เพิ่มเติมไปยังบริการของบุคคลที่สาม

• ไม่ต้องทำอะไรแตกต่าง
  คุณอาจเลือกไม่ใช้ที่พักที่เฉพาะเจาะจงกับคำขอที่ตั้งค่า sampleExtraction เป็น true ได้ ซึ่งจะทำให้กระบวนการตรวจจับเชิงความหมายช้าลงเนื่องจาก Looker Studio จะต้องดึงข้อมูลทั้งหมดสำหรับกระบวนการตรวจหาความหมาย นอกจากนี้ การดำเนินการดังกล่าวจะส่งผลต่ออัตราการส่งคำขอไปยังแหล่งข้อมูลภายนอก เนื่องจากคำขอตรวจจับเชิงความหมายจำนวนมากจะดำเนินการพร้อมกัน

รูปแบบที่ยอมรับสำหรับการตรวจหาประเภทความหมายอัตโนมัติ

วันที่และเวลา

• YYYY/MM/DD-HH:MM:SS
• YYYY-MM-DD [HH:MM:SS[.uuuuuu]]
• YYYY/MM/DD [HH:MM:SS[.uuuuuu]]
• YYYYMMDD [HH:MM:SS[.uuuuuu]]
• Sat, 24 May 2008 20:09:47 GMT
• 2008-05-24T20:09:47Z
• เวลา: Epoch สําหรับวินาที ไมโคร มิลลิวินาที และนาโน

ภูมิศาสตร์

• ชื่อหรือรหัสทวีป
• ชื่อหรือรหัสทวีปย่อย
• ชื่อหรือรหัสภูมิภาค
• ชื่อหรือรหัสประเทศ ดู ISO_3166-1 เพิ่มเติม
• ชื่อเมือง
• ค่าละติจูดและลองจิจูดที่คั่นด้วยคอมมา
• ชื่อและโค้ดพื้นที่การตลาดที่กำหนด (DMA)