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

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

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

สคีมาของปลั๊กอินจากชุมชนสำหรับใช้ลิงก์ข้อมูลและฟิลด์ Looker Studio

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

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

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

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

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

การตั้งค่าข้อมูลเชิงความหมายทำได้ 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'
    }
  }
];

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

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

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

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

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

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

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

1. ขอสคีมาโดยการเรียกใช้ฟังก์ชัน getSchema ของ Community Connector
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)