Google Places API กับการสแครป: ค่าใช้จ่าย ช่องว่างข้อมูล และสิ่งที่ผมจะเลือก

ไม่กี่เดือนก่อน มีนักพัฒนาคนหนึ่งใน Stack Overflow ตั้งคำถามที่ค้างคามาตั้งแต่ปี 2012: "Google Places API Place Details limited to 5 reviews?" ผ่านมา 14 ปี โหวตกันเป็นร้อย แต่คำตอบก็ยังเหมือนเดิม — ใช่ มันจำกัดไว้ที่ 5 รีวิวเท่านั้น ข้อจำกัดแค่จุดเดียวนี้ก็แทบจะอธิบายได้แล้วว่าทำไมเรื่องนี้ถึงถกกันไม่จบสักที

ถ้าคุณเคยต้องใช้ข้อมูลจาก Google Places ในสเกลใหญ่ ไม่ว่าจะเป็นการดึงรายชื่อลูกค้าที่มีแนวโน้มจะซื้อ รีวิวคู่แข่ง ข้อมูลทราฟฟิกคนเดิน หรือการเช็ก Local SEO คุณคงเคยเจอทางแยกเดียวกันนี้เหมือนกัน API ทางการของ Google Places นั้นสะอาด มีโครงสร้างชัด และมีเอกสารครบ แต่ก็ไม่ได้ส่งข้อมูลทุกอย่างที่คุณเห็นบนหน้า Google Maps กลับมา แถมบิลอาจพุ่งแรงมากเมื่อเกินฟรีแพ็กเกจ ส่วนการสแครปนั้นดึงข้อมูลได้มากกว่า คิดต้นทุนอีกแบบ แต่ก็มาพร้อมปัญหาของตัวเอง ทั้ง CAPTCHA ตัวเลือกตัวบอกตำแหน่งที่พังง่าย และพื้นที่สีเทาทางกฎหมาย ผมใช้เวลาพอสมควรกับทั้งสองฝั่ง ไล่ดูทั้งเอกสาร API ราคาแพ็กเกจ เครื่องมือสแครป และการใช้งานจริง บทความนี้เลยสรุปทุกอย่างไว้ให้แล้ว เราจะดูช่องว่างข้อมูลแบบฟิลด์ต่อฟิลด์ ต้นทุนจริงที่ 10K/100K/1M เรคคอร์ด ความจริงเรื่องการกันบอท และแนวทางใช้งานแบบไฮบริดที่ใช้ได้จริง แถมมีแผนผังการตัดสินใจให้ด้วย เพราะไม่มีใครอยากอ่าน 3,000 คำแล้วยังงงอยู่ว่าควรเลือกอะไร

Google Places API คืออะไร และให้ข้อมูลอะไรได้บ้างจริง ๆ?

Google Places API คือช่องทางทางการของ Google สำหรับดึงข้อมูลธุรกิจแบบมีโครงสร้าง เช่น ชื่อ ที่อยู่ เบอร์โทร คะแนน รีวิว รูปภาพ จากฐานข้อมูลของพวกเขา คุณส่งคำขอ HTTP แล้วได้ JSON ที่จัดรูปแบบมาเรียบร้อยกลับมาเลย มันคือท่อข้อมูลที่ Google อนุญาตอย่างเป็นทางการ

เวอร์ชันปัจจุบันของ Places API แบบ "New" จะจัดการทุกอย่างผ่าน field masks เวลาเรียก Place Details คุณต้องระบุฟิลด์ที่ต้องการแบบชัดเจน เช่น displayName, formattedAddress, rating, reviews, photos เป็นต้น และ Google จะคิดค่าบริการตามฟิลด์ที่อยู่ในระดับราคาสูงที่สุดที่คุณขอ ถ้าไม่ใส่ field mask จะเจอ error กลับมา ไม่ใช่คำตอบค่าเริ่มต้น ออกแบบมาแบบตั้งใจเลย: Google ต้องการให้คุณจ่ายเฉพาะสิ่งที่ใช้ และจ่ายแพงขึ้นสำหรับข้อมูลที่มีมูลค่าสูงกว่า

ฟิลด์ที่มีให้ใช้ ถูกแบ่งตามระดับราคาไว้ดังนี้:

ระดับ	ตัวอย่างฟิลด์	สิ่งที่คุณได้
Essentials	Place ID, ที่อยู่แบบจัดรูปแบบ, ตำแหน่ง, เมตาดาต้ารูปภาพ	ข้อมูลพื้นฐานด้านตัวตนและตำแหน่ง
Pro	ชื่อที่แสดง, สถานะธุรกิจ, Google Maps URI, ประเภทหลัก	ข้อมูลธุรกิจที่ละเอียดขึ้น
Enterprise	คะแนน, จำนวนผู้ให้คะแนน, เว็บไซต์, เบอร์โทร, เวลาทำการ, ระดับราคา	ฟิลด์ที่คนทำธุรกิจต้องใช้จริง
Enterprise + Atmosphere	รีวิว, สรุปรีวิว, สรุปจาก AI, สิ่งอำนวยความสะดวก, ที่จอดรถ, ซื้อกลับบ้าน/เดลิเวอรี	ข้อมูลครบและแพงที่สุด

เอนด์พอยต์หลักที่คนส่วนใหญ่มักใช้คือ: Autocomplete สำหรับค้นหาแบบพิมพ์ไปค้นหาไป, Text Search และ Nearby Search สำหรับค้นหาสถานที่, Place Details สำหรับเติมข้อมูลให้สถานที่ที่รู้แล้ว และ Place Photos สำหรับรูปภาพ

ข้อจำกัดสำคัญที่ต้องรู้:

• รีวิว: Place resource ส่งคืนรีวิวได้สูงสุด 5 รีวิวต่อสถานที่ และเรียงตามความเกี่ยวข้องเท่านั้น ไม่มี 50 ไม่มี "ทั้งหมด" มีแค่ห้า
• รูปภาพ: จำกัดไว้ที่ 10 photo references ต่อสถานที่ใน Place resource
• Popular times / live busyness: ไม่ได้เป็นฟิลด์มาตรฐานของ Places API แม้ Google จะ ยืนยันว่ามีข้อมูลนี้ ในฝั่งผู้ใช้ทั่วไป (อิงจาก Location History แบบรวมและไม่ระบุตัวตน) และ บล็อกของ Maps ก็อธิบายการทำงานไว้ แต่ รายการฟิลด์ ไม่มีข้อมูลนี้
• ส่วน Q&A: ไม่มีการเปิดให้เข้าถึง
• คู่แข่งในหัวข้อ "People also search for": ไม่มีให้
• เมนู / รายการราคา: ไม่ใช่ฟิลด์มาตรฐาน

ใครมักใช้ Google Places API?

• บริษัทโลจิสติกส์ ที่ใช้ยืนยันและแปลงพิกัดที่อยู่
• แอปท่องเที่ยวและโรงแรม ที่แสดงโรงแรม ร้านอาหาร และสถานที่ใกล้เคียง
• แพลตฟอร์มอสังหาฯ ที่เติมข้อมูลธุรกิจท้องถิ่นลงในประกาศทรัพย์สิน
• เอเจนซี Local SEO ที่เช็กความสอดคล้องของ NAP (name, address, phone)
• ทีมขาย ที่สร้างลีดลิสต์จาก Place ID และข้อมูลธุรกิจพื้นฐาน

ถ้าโจทย์ของคุณคือ "ฉันต้องการข้อมูลสถานที่แบบมีโครงสร้างไปใช้ในแอปจริง" API คือจุดเริ่มต้นที่ถูกต้อง แต่ถ้าโจทย์มีคำว่า "รีวิวทั้งหมด" "popular times" หรือ "วิเคราะห์คู่แข่ง" อยู่ด้วย — อ่านต่อ

แล้วการ "สแครป" ข้อมูล Google Places คืออะไร?

Web scraping คือการใช้ซอฟต์แวร์ดึงข้อมูลจากหน้าเว็บโดยอัตโนมัติ — ในกรณีนี้คือ Google Maps หรือผลลัพธ์จาก Google Search — แทนที่จะเรียกผ่าน API ทางการ ตัวสแครปเปอร์จะอ่านหน้าเว็บเหมือนเบราว์เซอร์ของคุณ แล้วดึงชิ้นส่วนที่มีโครงสร้างออกมา เช่น ชื่อธุรกิจ ที่อยู่ ข้อความรีวิว คะแนนดาว กราฟ popular times Q&A คำแนะนำคู่แข่ง แกลเลอรีรูปภาพทั้งหมด และข้อมูลอื่น ๆ ที่แสดงอยู่บนหน้าจอ

ความต่างสำคัญคือ: API ให้สิ่งที่ Google เลือกจะเปิดเผย ส่วนการสแครปจะดึงได้ตามหลักว่า ในทางทฤษฎีทุกอย่างที่มนุษย์มองเห็นบนหน้าเว็บ

แต่คำว่า "สแครป" ไม่ได้มีแค่แบบเดียว มี 3 แนวทางหลักที่ต่างกันมาก และ trade-off ของแต่ละแบบก็สำคัญไม่น้อย

สคริปต์เขียนเอง vs API สำหรับสแครปแบบมีบริการจัดการ vs เครื่องมือแบบไม่ต้องเขียนโค้ด

แนวทาง	วิธีทำงาน	เหมาะกับใคร	จุดแลกเปลี่ยนหลัก
สคริปต์เขียนเอง (Puppeteer, Playwright, Selenium)	คุณเขียนและดูแลสคริปต์เบราว์เซอร์แบบ headless ให้เข้า Google Maps และแยก DOM เอง	นักพัฒนาที่ต้องการควบคุมเต็มที่และมี logic เฉพาะ	ภาระดูแลสูงสุด — selector พังเมื่อ Google เปลี่ยน UI
Managed scraping APIs (Thunderbit API, SerpApi, Outscraper)	ส่ง URL หรือ query ไปยัง API แล้วให้ระบบจัดการ rendering, anti-bot และ parsing จากนั้นคืนข้อมูลแบบมีโครงสร้าง	นักพัฒนาที่อยากได้ผลลัพธ์เป็นโครงสร้างโดยไม่ต้องดูแลสแครปเปอร์เอง	ราคาและคุณภาพแตกต่างกัน ต้องพึ่งผู้ให้บริการภายนอก
ส่วนขยายเบราว์เซอร์แบบไม่ต้องโค้ด (Thunderbit Chrome Extension)	ดึงข้อมูลแบบคลิกเลือกในเบราว์เซอร์ — AI แนะนำฟิลด์ คุณกด "Scrape" แล้วส่งออกไปยัง Sheets/Excel	ผู้ใช้งานธุรกิจ นักการตลาด ทีมขาย ที่ต้องการข้อมูลลงสเปรดชีตเร็ว ๆ	ยืดหยุ่นน้อยกว่าสำหรับ pipeline ซับซ้อน และขึ้นกับคุณภาพ AI ของเครื่องมือ

สรุปสั้น ๆ: เขียนเอง = ยืดหยุ่นสุดแต่ต้องดูแลมากสุด, Managed API = ได้ข้อมูลเป็นโครงสร้างโดยไม่ต้องบำรุงรักษา, No-code = เร็วสุดสำหรับคนไม่ใช่สายเทคนิค

Google Places API vs การสแครป: เทียบข้อมูลแบบฟิลด์ต่อฟิลด์

นี่คือภาพที่ผมอยากให้มีตั้งแต่เริ่มหาข้อมูลเรื่องนี้ ทุกฟิลด์ที่ผู้ใช้งานธุรกิจหรือนักพัฒนาอาจต้องใช้ เอามาเทียบกันตรง ๆ:

ฟิลด์ข้อมูล	Google Places API	Web Scraping
ชื่อธุรกิจ	✅ ครบ (Pro tier)	✅ ครบ
ที่อยู่ / ตำแหน่ง	✅ ครบ (Essentials tier)	✅ ครบ
เบอร์โทร	✅ Enterprise tier	✅ เมื่อแสดงบนหน้า
URL เว็บไซต์	✅ Enterprise tier	✅ เมื่อแสดงบนหน้า
คะแนนรวม	✅ Enterprise tier	✅ ครบ
จำนวนผู้ให้คะแนน	✅ Enterprise tier	✅ ครบ
รีวิวรายรายการ (ข้อความ + คะแนน)	⚠️ สูงสุด 5 รีวิว	✅ รีวิวที่มีทั้งหมด
Popular times / live busyness	❌ ไม่ใช่ฟิลด์มาตรฐานของ API	✅ ดึงได้ (ถ้ามีการ render บนหน้า)
ส่วน Q&A	❌ ไม่มีการเปิดให้เข้าถึง	✅ ดึงได้
เมตาดาต้ารูปภาพ	✅ ผ่าน Photos endpoint ได้ สูงสุด 10 references	✅ แกลเลอรีครบ
เมนู / รายการราคา	❌ ไม่ใช่ฟิลด์มาตรฐาน	⚠️ เมื่อมีแสดงบนหน้า
"People also search for" (คู่แข่ง)	❌ ไม่มีให้	✅ ดึงได้
เวลาทำการ	✅ Enterprise tier	✅ เมื่อแสดงบนหน้า
ระดับราคา	✅ Enterprise tier	✅ เมื่อแสดงบนหน้า
Place ID	✅ แข็งแรงและเชื่อถือได้ (Essentials)	⚠️ ทำได้ แต่ API คือแหล่งอ้างอิงหลัก
Google Maps URI	✅ Pro tier	✅ คือ URL ของหน้า
การตอบกลับจากเจ้าของต่อรีวิว	⚠️ ตรวจสอบความพร้อมใช้งานปัจจุบัน	✅ มักมองเห็นได้
ตำแหน่งใน SERP / map pack	❌ ไม่ใช่จุดประสงค์ของ API	✅ ผ่านการสแครป SERP

ช่องว่างหลักคือ: ถ้าคุณต้องใช้ชุดรีวิวเต็ม ๆ เพื่อวิเคราะห์ sentiment, ติดตามชื่อเสียง, หรือทำ benchmark เทียบคู่แข่ง API อย่างเดียวไม่พอ รีวิว 5 รายการต่อสถานที่เป็นแค่ตัวอย่าง ไม่ใช่ชุดข้อมูลจริง

แล้ว popular times กับรูปแบบทราฟฟิกคนเดินล่ะ? ก็เรื่องเดียวกัน ถ้าคุณเป็นที่ปรึกษาด้านค้าปลีกหรือวิเคราะห์อสังหาฯ เชิงพาณิชย์ การสแครปคือทางเดียว เพราะข้อมูลนี้ไม่ได้อยู่ใน API

ในอีกมุมหนึ่ง ถ้าคุณต้องการ Place ID ที่เป็นแหล่งอ้างอิงหลัก ที่อยู่แบบมีโครงสร้างสำหรับ geocoding หรือใช้สร้าง store locator API จะสะอาดกว่า เชื่อถือได้กว่า และเป็นทางการกว่า

ต้นทุนจริง: Google Places API vs การสแครป ที่ 10K, 100K และ 1M เรคคอร์ด

ต้นทุนคือส่วนที่คนมักเข้าใจผิดมากที่สุด หลายคนเริ่มจากฟรีแพ็กเกจของ API ทำต้นแบบขึ้นมา แล้วพอเริ่มสเกลก็เจอบิลที่ทำเอาหน้าซีด ฝั่งสแครปเอง หลายคนก็มักประเมินต่ำไปทั้งค่าพร็อกซีและเวลาของนักพัฒนา

มาลองคำนวณกัน

สรุปราคาของ Google Places API

Google ปรับโครงสร้างราคา Maps Platform ใหม่ในเดือนมีนาคม 2025 โดยแทนที่เครดิตฟรีเครดิต $200 ต่อเดือนแบบเดิมด้วยเพดานการใช้งานฟรีตาม SKU และการคิดราคาแบบแบ่งตามปริมาณ ราคาปัจจุบัน ทำงานประมาณนี้:

• ฟิลด์ Essentials (Place Details): ฟรี 10,000 คำขอ/เดือน จากนั้น $5.00 ต่อ 1,000 คำขอจนถึง 100K
• ฟิลด์ Pro (Place Details): ฟรี 5,000 จากนั้น $7.00/1K
• ฟิลด์ Enterprise (Place Details): ฟรี 1,000 จากนั้น $20.00/1K
• Enterprise + Atmosphere (รีวิว, สิ่งอำนวยความสะดวก): ฟรี 1,000 จากนั้น $25.00/1K

จุดสำคัญคือ: ถ้า field mask ของคุณมีฟิลด์ระดับ Enterprise + Atmosphere แค่ฟิลด์เดียว เช่น reviews คำขอทั้งหมดของคุณจะถูกคิดราคาในระดับนั้น และเวิร์กโฟลว์จริงมักต้องเรียกหลาย SKU ต่อกัน — เช่น Text Search Pro เพื่อค้นหาสถานที่ แล้ว Place Details Enterprise + Atmosphere เพื่อเติมข้อมูล — ทำให้ต้นทุนรวมทบกัน

การ "ค้นหาครั้งเดียว" จึงแทบไม่เคยเป็นคำขอที่คิดเงินแค่ครั้งเดียวจริง ๆ

ต้นทุนการสแครป: เครื่องมือ พร็อกซี และเวลานักพัฒนา

ต้นทุนการสแครปแบ่งได้ 3 ก้อน:

1. ค่าสมาชิกเครื่องมือหรือเครดิต API: Managed scraping API คิดเงินตามคำขอ เครดิต หรือเรคคอร์ด SerpApi คิดตามการค้นหา Outscraper ใช้จ่ายตามเรคคอร์ดแบบ pay-as-you-go ส่วน Thunderbit's API ใช้ระบบเครดิต (Extract = 20 credits/request) และ Thunderbit Chrome Extension คิด 1 เครดิตต่อผลลัพธ์ 1 แถว
2. ค่าพร็อกซี (เฉพาะ DIY): พร็อกซีแบบ residential สำหรับสแครป Google Maps มักอยู่ราว $50–$300/เดือน ขึ้นกับปริมาณและผู้ให้บริการ
3. เวลานักพัฒนา (เฉพาะ DIY): เวลาสร้างและดูแลสคริปต์ Puppeteer/Playwright นี่แหละคือต้นทุนแฝงที่ทำให้การทำเองไม่คุ้มในหลายกรณี (จะอธิบายต่อด้านล่าง)

ตารางเปรียบเทียบต้นทุน: API vs การสแครปเมื่อสเกลใหญ่ขึ้น

ขนาดงาน	Google Places API (Enterprise + Atmosphere)	Managed Scraping API (โดยประมาณ)	DIY Scraping (พร็อกซี + เวลาพัฒนา)
10K เรคคอร์ด/เดือน	~$225 (ฟรี 1K, 9K × $25/1K)	~$50–$150 ขึ้นกับผู้ให้บริการ	~$50 ค่าพร็อกซี + 2–4 ชม. dev/เดือน
100K เรคคอร์ด/เดือน	~$2,475 (หลังหมดเพดานฟรี จะคิดตาม tier ปริมาณ)	~$250–$500	~$150 ค่าพร็อกซี + 8–16 ชม. dev/เดือน
1M เรคคอร์ด/เดือน	~$17,975 (tier ปริมาณช่วยลดต้นทุนต่อหน่วย แต่ยอดรวมยังสูง)	~$1,500–$3,000	~$300 ค่าพร็อกซี + 20+ ชม. dev/เดือน + ความเสี่ยงสคริปต์พัง

หมายเหตุ: ตัวเลขฝั่ง API อิง volume tiers ที่เผยแพร่ สำหรับ Place Details Enterprise + Atmosphere หลังหักโควตาฟรี 1K ส่วน managed scraping API เป็นช่วงประมาณการจากหลายผู้ให้บริการ เวลา dev ของ DIY คิดจากต้นทุนแรงงาน $50–$100/ชั่วโมง

รูปแบบมันชัดมาก: ถ้าใช้งานระดับงานอดิเรกหรือไม่ถึง 10K เรคคอร์ด ฟรีแพ็กเกจของ API อาจทำให้มันเป็นตัวเลือกที่ถูกที่สุด โดยเฉพาะถ้าคุณใช้แค่ฟิลด์ Essentials หรือ Pro แต่ถ้าเป็นระดับธุรกิจ 100K+ ต้นทุน API จะกระโดดขึ้นแรงมาก โดยเฉพาะเมื่อใช้ฟิลด์ที่ละเอียด ถ้าเป็นระดับองค์กร 1M+ API อาจแตะหลักหลายหมื่นดอลลาร์ต่อเดือน ขณะที่การสแครปหรือบริการชุดข้อมูลจะดูคุ้มค่ากว่า — ถ้าคุณจำเป็นต้องใช้ฟิลด์ที่ API ไม่มี

ถ้าคุณต้องการแค่ที่อยู่กับ Place ID อย่าสแครป ใช้ API ถูกกว่าและเหมาะกว่า ข้ออ้างเรื่องต้นทุนของการสแครปจะมีน้ำหนักก็ต่อเมื่อคุณต้องการข้อมูลที่ API คืนให้ไม่ได้

เช็กความจริงเรื่องกันบอท: ทำไมสแครป Google แบบ DIY ถึงพังบ่อย

นี่คือส่วนที่สายสแครปมักข้ามไป Google ไม่อยากให้คุณสแครป Google Maps และพวกเขามีระบบป้องกันหลายชั้นที่อัปเดตอยู่ตลอด

ระบบป้องกันหลายชั้นของ Google

• reCAPTCHA: เบราว์เซอร์อัตโนมัติจะเจอ CAPTCHA บ่อยกว่าผู้ใช้จริงมาก
• การ render ด้วย JavaScript ฝั่งไคลเอนต์: Google Maps เป็นเว็บแอปที่ใช้ JavaScript หนักมาก ขอแค่ HTTP request ตรง ๆ จะไม่เห็นคอนเทนต์ที่ render แล้ว ต้องใช้ headless browser เต็มรูปแบบ
• Browser fingerprinting: Google ตรวจจับเบราว์เซอร์ headless ผ่าน canvas fingerprint, WebGL, navigator properties และสัญญาณอื่น ๆ
• การจำกัดอัตราจาก IP: ถ้าส่งคำขอเยอะจาก IP เดิม หรือ subnet พร็อกซีเดิม จะถูกบล็อก
• โครงสร้าง DOM เปลี่ยนบ่อย: Google ปรับโครงสร้างหน้าเว็บอยู่เรื่อย ๆ — ความเห็นร่วมใน Reddit และ issue บน GitHub คือ selector มักพังทุกไม่กี่สัปดาห์ถึงหลายเดือน

ตัวหลังนี่แหละคือฆาตกรเงียบ สคริปต์ Puppeteer ที่เคยทำงานได้ดีในเดือนมิถุนายน อาจคืนค่าเปล่าในเดือนกรกฎาคม เพราะ Google เปลี่ยนชื่อ CSS class หรือจัด div ใหม่

ต้นทุนแฝงของการดูแลสคริปต์ DIY

ทุกครั้งที่ Google เปลี่ยน DOM ทีมของคุณต้อง:

1. สังเกตว่าสคริปต์พังแล้ว (หวังว่าจะก่อนข้อมูลเสียแพร่ต่อ)
2. ตรวจสอบโครงสร้างหน้าใหม่
3. ปรับ selector รับมือ CAPTCHA แบบใหม่ และจูน retry logic
4. ทดสอบและ deploy ใหม่

ในระยะหนึ่งปี เวลาในการดูแลแบบนี้อาจสูงกว่าค่าสมาชิกของ managed scraping API ได้ง่าย ๆ ผมเคยเห็นทีมเสียเวลา dev กว่า 40 ชั่วโมงต่อปีเพื่อแค่ประคอง Google Maps scraper ให้ยังใช้งานได้ — และนี่เป็นตัวเลขที่ค่อนข้างอนุรักษ์นิยมสำหรับระบบที่ซับซ้อนปานกลาง

ทำไม Managed Scraping API ถึงมีอยู่

ภาระดูแลแบบนี้แหละที่ทำให้บริการอย่าง Thunderbit's API, SerpApi, และ Outscraper เกิดขึ้น พวกเขารับความซับซ้อนด้าน anti-bot ไปจัดการให้ — ทั้งการ render JS, การแก้ CAPTCHA, การสลับพร็อกซี, การดูแล selector — แล้วส่งกลับข้อมูลแบบมีโครงสร้าง

เอ็นด์พอยต์ POST /extract ของ Thunderbit ที่ตั้ง renderMode: "full" จะจัดการหน้าเว็บที่ใช้ JavaScript หนักอย่าง Google Maps แล้วส่งกลับ JSON แบบตรง schema ไม่ใช่ HTML ดิบที่ยังต้องมานั่ง parse ต่อ MCP server ก็ขยายความสามารถนี้ไปยัง AI agent — ไม่ว่าจะเป็น Claude, Cursor หรือ workflow ที่ใช้ LLM ตัวอื่น ก็สามารถดึงข้อมูล Google Maps ระหว่างงานได้โดยไม่ต้องออกจากสภาพแวดล้อมเดิม

สำหรับคนไม่ถนัดเทคนิค Thunderbit Chrome Extension คือทางเลือกแบบไม่ต้องดูแลอะไรเลย: เปิดหน้า Google Maps คลิก "AI Suggest Fields" คลิก "Scrape" แล้วส่งออกไป Sheets ไม่มี selector ไม่มีพร็อกซี ไม่มี debug

SerpApi และ Outscraper ก็เป็นตัวเลือกที่ดีเช่นกัน แต่ต่างกันที่โมเดลราคาและรูปแบบ output SerpApi คืน JSON แบบมีโครงสร้างตามการค้นหา ส่วน Outscraper คิดเงินตามเรคคอร์ดด้วยระบบ pay-as-you-go การเลือกที่เหมาะขึ้นกับปริมาณ งบ และว่าคุณต้องการ JSON ที่มีโครงสร้างครบ หรือโอเคกับข้อมูลกึ่งโครงสร้างที่ต้องนำไปแปลงต่อ

แนวทางไฮบริด: ใช้ Google Places API และการสแครปร่วมกัน

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

เมื่อ API ทางการชนะ

• Autocomplete ในแอปที่ใช้งานจริง: latency ต่ำ, สอดคล้อง ToS, เชื่อถือได้ มี SLA ไม่มีอะไรต้องเถียง
• แบ็กเอนด์ของแอปที่อิงตำแหน่ง: store locator, ยืนยันที่อยู่, จับคู่ Place ID API มีโครงสร้าง มีซัพพอร์ต และมีเอกสารครบ
• อินทิเกรตที่อ่อนไหวเรื่องคอมพลายแอนซ์: สัญญาองค์กร, ผลิตภัณฑ์ที่เปิดให้สาธารณะใช้, หรือบริบทใดก็ตามที่การทำตาม Google ToS เป็นสิ่งต่อรองไม่ได้

เมื่อการสแครปชนะ

• ดึงรีวิวทั้งหมด (5K+ รีวิวต่อสถานที่): สำหรับ sentiment analysis, ติดตามชื่อเสียง, เปรียบเทียบคู่แข่ง API จำกัดไว้แค่ 5 รีวิวต่อสถานที่ จึงใช้ไม่ได้
• ดึงลีดลิสต์ครั้งเดียว: คุ้มกว่าในงาน batch ที่ไม่มีค่าใช้จ่ายต่อเนื่อง เครื่องมือแบบ no-code อย่าง Thunderbit สามารถสแครปรายชื่อธุรกิจแล้วส่งออกเป็นสเปรดชีตได้ในไม่กี่นาที
• วิเคราะห์ popular times / foot traffic: ไม่มีผ่าน API ชัด ๆ
• ข้อมูล Q&A และ "people also search for" ของคู่แข่ง: มีให้เห็นเฉพาะบนหน้าเว็บ ไม่ได้อยู่ใน API

เมื่อแนวทางไฮบริดสมเหตุสมผล

• ติดตามราคา/คะแนนต่อเนื่อง: ใช้ API สำหรับข้อมูลโครงสร้างพื้นฐาน (Place ID, ที่อยู่, คะแนนรวม) แล้วใช้สแครปเจาะข้อมูลลึกที่ API ไม่มี (รีวิวทั้งหมด, popular times)
• เวิร์กโฟลว์ enrichment: ใช้ API เพื่อเอา Place ID และข้อมูลธุรกิจหลัก จากนั้นสแครปแต่ละหน้ารายการเพื่อดึงชุดรีวิวเต็ม, Q&A และบริบทคู่แข่ง
• การมอนิเตอร์แบบตั้งเวลา: Scheduled scraper ของ Thunderbit (สำหรับผู้ใช้ no-code) หรือ batch extract ผ่าน CLI ผูกกับ cron (สำหรับนักพัฒนา) ช่วยให้งานสแครปซ้ำ ๆ ทำได้โดยไม่ต้องมีโครงสร้างเฉพาะทางเอง

ตารางตัดสินใจตามกรณีใช้งาน

กรณีใช้งาน	วิธีที่แนะนำ	เหตุผล
Autocomplete ในแอปที่ใช้งานจริง	✅ API ทางการ	latency ต่ำ, สอดคล้อง ToS, เชื่อถือได้
ดึงชุดรีวิวเต็ม 5K+ รายการ	✅ การสแครป / Scraping API	API จำกัดไว้ 5 รีวิวต่อสถานที่
ดึงรายชื่อลีดธุรกิจท้องถิ่นครั้งเดียว	✅ การสแครป (หรือ Thunderbit extension)	คุ้มกว่าสำหรับงาน batch; ไม่มีบิลต่อเนื่อง
วิเคราะห์ popular times / foot traffic	✅ สแครปเท่านั้น	ไม่มีใน API
ติดตามราคา/คะแนนต่อเนื่อง	⚠️ ไฮบริด	API สำหรับข้อมูลพื้นฐาน สแครปสำหรับข้อมูลลึก
แบ็กเอนด์ของแอปที่อิงตำแหน่ง	✅ API ทางการ	มีโครงสร้าง มีซัพพอร์ต มี SLA
ติดตามอันดับ SERP ของ Local SEO	✅ สแครป / SERP API	ไม่ใช่หน้าที่ของ Places API
คู่แข่ง "people also search for"	✅ สแครปเท่านั้น	ไม่มีให้ใน API

แผนผังการตัดสินใจ: Google Places API vs การสแครป — ควรเลือกอะไร?

แทนที่จะตอบแบบกว้าง ๆ ว่า "แล้วแต่กรณี" นี่คือเฟรมเวิร์กการตัดสินใจที่ชัดเจน ลองตอบ 4 คำถามนี้:

1. คุณต้องการข้อมูลแบบเรียลไทม์ในแอป production ไหม? → ใช่: ใช้ Official API มันมีซัพพอร์ต มี SLA และสอดคล้อง ToS จบตรงนี้ → ไม่ใช่: ไปต่อ

2. คุณต้องการข้อมูลที่ API ไม่ส่งกลับมาใช่ไหม (เช่น รีวิวเต็ม, popular times, Q&A)? → ใช่: จำเป็นต้องสแครป API ให้ข้อมูลนี้ไม่ได้จริง ๆ → ไม่ใช่: ไปต่อ

3. เดือนหนึ่งต้องจัดการกี่เรคคอร์ด? → ต่ำกว่า 10K: API น่าจะถูกกว่า โดยเฉพาะถ้าคุณใช้แค่ฟิลด์ Essentials หรือ Pro ฟรีแพ็กเกจครอบคลุมงานได้เยอะในสเกลนี้ → มากกว่า 10K: การสแครปหรือ managed scraping API มักคุ้มค่ากว่า โดยเฉพาะถ้าข้อมูลที่ต้องการมีความลึก

4. คุณมีทรัพยากรนักพัฒนาเพื่อสร้างและดูแลสแครปเปอร์ไหม? → มี: ทำ DIY ด้วย Puppeteer/Playwright ได้ ควบคุมได้เต็มที่ แต่ต้องเผื่องบดูแลต่อเนื่อง → ไม่มี: ใช้ managed scraping API (Thunderbit API, SerpApi, Outscraper) หรือเครื่องมือ no-code (Thunderbit Chrome Extension)

เปรียบเทียบทางเลือกสำหรับนักพัฒนาแบบเร็ว ๆ

เครื่องมือ	โมเดลราคา	รูปแบบผลลัพธ์	รับมือ Anti-bot	รองรับงาน batch
Thunderbit API / MCP	ใช้เครดิต (Extract = 20 credits/request)	JSON มีโครงสร้างตรง schema	✅ JS rendering, proxy rotation, geo-routing	✅ สูงสุด 100 URLs ต่อ batch
SerpApi	คิดตามการค้นหา (แผนแบบ tier)	JSON มีโครงสร้าง	✅	✅ ผ่านพารามิเตอร์ API
Outscraper	คิดตามเรคคอร์ด (pay-as-you-go)	JSON / CSV	✅	✅ ผ่าน task queue
DIY (Puppeteer/Playwright)	พร็อกซี + เวลาพัฒนา	HTML ดิบ (คุณต้อง parse เอง)	❌ คุณต้องจัดการเอง	✅ เท่าที่คุณสร้างไว้

จุดเด่นของ Thunderbit API คือคืน JSON แบบมีโครงสร้างตรงตาม JSON Schema ที่คุณกำหนด ไม่ใช่ HTML หรือ Markdown ดิบที่ยังต้อง parse ต่อ ถ้าคุณป้อนต่อเข้า LLM pipeline หรือโหลดเข้าฐานข้อมูล นั่นช่วยประหยัดเวลาหลังบ้านได้จริง

Thunderbit เข้ามาเกี่ยวข้องตรงไหนบ้าง (สำหรับทั้งผู้ใช้ธุรกิจและนักพัฒนา)

เราออกแบบ Thunderbit มาเพื่อเชื่อมช่องว่างระหว่าง "ฉันต้องการข้อมูล Google Maps" กับ "ฉันไม่อยากกลายเป็นวิศวกรโครงสร้างพื้นฐานด้านสแครป" นี่คือวิธีใช้งานสำหรับทั้งสองกลุ่ม

สำหรับคนไม่ถนัดเทคนิค: Chrome Extension

1. เปิดหน้า Google Maps — จะเป็นหน้าผลค้นหาหรือหน้าธุรกิจรายรายการก็ได้
2. คลิก "AI Suggest Fields" — AI ของ Thunderbit อ่านหน้าแล้วเสนอคอลัมน์ให้ เช่น ชื่อธุรกิจ ที่อยู่ คะแนน รีวิว เบอร์โทร ฯลฯ
3. คลิก "Scrape" — ส่วนขยายจะดึงข้อมูลออกมาเป็นตารางแบบมีโครงสร้าง ใช้ cloud mode ได้พร้อมกันสูงสุด 50 หน้า
4. สแครปหน้ารอง — คลิก "Scrape Subpages" เพื่อเข้าไปแต่ละรายการแล้วดึงรายละเอียดแบบเต็ม
5. ส่งออก — ไปยัง Excel, Google Sheets, Airtable หรือ Notion ได้ ส่งออกข้อมูลฟรี ไม่มี paywall

ถ้าต้องติดตามแบบเป็นประจำ — เช่น เช็กคะแนนคู่แข่งรายสัปดาห์ หรือรายชื่อธุรกิจใหม่ — scheduled scraper จะรันอัตโนมัติตามรอบที่คุณกำหนด

สำหรับนักพัฒนา: API, MCP Server และ CLI

• POST /extract พร้อม JSON Schema: ส่ง URL ของ Google Maps ระบุฟิลด์ที่ต้องการ แล้วรับ JSON แบบมีโครงสร้างกลับมา ตั้ง renderMode: "full" สำหรับหน้าที่ใช้ JavaScript หนัก Thunderbit จัดการ rendering, anti-bot, proxy rotation และ geo-routing ให้
• POST /distill: ดึง Markdown ที่สะอาดจากทุกหน้า — เหมาะกับ LLM pipeline ที่ต้องใช้คอนเทนต์ดิบมากกว่าฟิลด์ที่มีโครงสร้าง 1 เครดิต/คำขอ เทียบกับ 20 สำหรับ Extract
• MCP Server: ให้ AI agents เช่น Claude, Cursor สแครปข้อมูล Google Maps ระหว่างงานได้ รองรับ distillation, structured extraction, field suggestions และงาน batch สูงสุด 100 URLs
• CLI: thunderbit batch extract --file urls.txt --schema places.json สำหรับงานสแครปแบบตั้งเวลา หรือผูกกับ CI/CD

ราคาเครดิต: Extract = 20 credits/request, Distill = 1 credit/request เครดิต API คิดตามคำขอ ไม่ใช่ตามจำนวนแถว (ต่างจาก extension ที่ 1 เครดิต = 1 แถวผลลัพธ์) ตรวจสอบ Thunderbit Pricing สำหรับแพ็กเกจปัจจุบัน

ประเด็นทางกฎหมายและข้อกำหนดการใช้งาน

ขอพูดสั้น ๆ แบบตรงไปตรงมา — ไม่ขู่ ไม่ขายของ

Google Places API มาพร้อมข้อกำหนดที่ชัดเจน: terms เฉพาะของบริการจาก Google ระบุว่าเนื้อหาจาก Places API สามารถใช้ได้โดยไม่ต้องมี Google Map แต่ห้ามใช้กับแผนที่ที่ไม่ใช่ของ Google พิกัดละติจูด/ลองจิจูดแคชได้สูงสุด 30 วันปฏิทินต่อเนื่อง ส่วน Place ID เก็บได้ไม่มีกำหนด ต้องมีการระบุแหล่งที่มาสำหรับรายละเอียด รูปภาพ และรีวิว

การสแครป Google Maps อาจขัดกับ Terms of Service ของ Google ได้ การบังคับใช้มีหลายระดับ — ตั้งแต่ IP block, CAPTCHA ไปจนถึงการดำเนินคดีในบางกรณีที่พบไม่บ่อย Managed scraping API โดยทั่วไปช่วยแบ่งเบาภาระด้านคอมพลายแอนซ์บางส่วนให้ผู้ใช้ แต่ไม่ใช่เกราะคุ้มกันทางกฎหมาย

สำหรับแอป production ที่ให้บริการผู้ใช้ปลายทาง การใช้ API ทางการเป็นทางเลือกที่ปลอดภัยกว่า สำหรับงานวิจัยภายใน การวิเคราะห์เป็นชุด และ competitive intelligence การสแครปเป็นแนวปฏิบัติที่พบได้ในอุตสาหกรรม ปรึกษาทนายของคุณเองสำหรับ workflow เชิงพาณิชย์

ถ้าให้ผมเลือกจริง ๆ จะเลือกอะไร และเพราะอะไร?

หลังจากไล่ดูทั้ง price SKU, รายการฟิลด์, กระทู้ในคอมมูนิตี้ และเอกสารเครื่องมือต่าง ๆ นี่คือข้อสรุปของผม:

• ใช้ API ทางการ เมื่อคุณต้องการข้อมูลเรียลไทม์ที่สอดคล้อง ToS ในแอป production หรือเมื่อฟิลด์ระดับ Essentials/Pro เพียงพอ และปริมาณต่ำกว่า 10K/เดือน ฟรีแพ็กเกจค่อนข้าง generous ในสเกลเล็ก และคุณภาพข้อมูลเชื่อถือได้แน่นอน
• ใช้การสแครป (ผ่าน API ที่มีบริการจัดการหรือเครื่องมือ no-code) เมื่อคุณต้องการรีวิวเต็ม, popular times, Q&A, บริบทคู่แข่ง หรือฟิลด์ที่ API ไม่เปิดให้ใช้ และถ้าปริมาณคุณเกิน 10K–100K เรคคอร์ด/เดือน พร้อมขอข้อมูลระดับลึก (Enterprise + Atmosphere) บิล API จะยากมากที่จะอธิบายว่าคุ้ม
• ใช้ทั้งสองอย่าง เมื่อเวิร์กโฟลว์ของคุณต้องมีทั้ง Place ID และข้อมูลพื้นฐานที่เป็น canonical (API) บวกกับข้อมูลเชิงลึกจากหน้าสาธารณะ (การสแครป) วิธีนี้เกิดขึ้นจริงบ่อยกว่าที่บทความส่วนใหญ่มักยอมรับ

จุดหักเหของต้นทุนคือ: ต่ำกว่า ~10K เรคคอร์ด/เดือน และใช้ฟิลด์พื้นฐาน API จะง่ายและบ่อยครั้งฟรี แต่เหนือกว่านั้น โดยเฉพาะข้อมูลเชิงลึก การสแครปจะคุ้มกว่ามาก ที่ 1M เรคคอร์ดพร้อมฟิลด์ Enterprise + Atmosphere คุณอาจจ่ายราว ~$18K/เดือนบน API ขณะที่ managed scraper ใช้เพียงเศษเสี้ยวของตัวเลขนั้น

ถ้าคุณอยากลองเทียบด้วยตัวเอง Thunderbit Chrome Extension คือวิธีที่เร็วที่สุดในการดูว่าการสแครปดึงอะไรได้บ้างเมื่อเทียบกับ API ส่วน workflow สำหรับนักพัฒนา ดูได้จาก Thunderbit API docs ที่มีทุกอย่างให้เริ่มต้น และถ้าอยากอ่านเพิ่มเกี่ยวกับ web scraping without coding หรือ AI web scraping โดยรวม เราก็มีเขียนไว้ในบล็อกเยอะแล้ว

สรุปประเด็นสำคัญ

• Google Places API เหมาะกับแอป production, autocomplete และการค้นหาสถานที่แบบมีโครงสร้าง — แต่จำกัดรีวิวไว้ที่ 5 จำกัดรูปภาพไว้ที่ 10 และไม่เปิด popular times, Q&A หรือคำแนะนำคู่แข่ง
• การสแครปดึงข้อมูลทุกอย่างที่มองเห็นบนหน้า Google Maps ได้ รวมถึงชุดรีวิวเต็มและข้อมูล popular times แต่ต้องจัดการระบบกันบอทเอง หรือจ่ายให้บริการที่จัดการให้
• ถ้าปริมาณต่ำกว่า 10K เรคคอร์ด/เดือน ฟรีแพ็กเกจของ API มักเป็นตัวเลือกที่ถูกที่สุด พอเกิน 100K การสแครปหรือ managed scraping API มักคุ้มกว่าสำหรับข้อมูลเชิงลึก
• สแครปเปอร์แบบ DIY พังบ่อยเพราะระบบกันบอทและการเปลี่ยน DOM ของ Google — เผื่อเวลา dev อย่างน้อย 40+ ชั่วโมง/ปีสำหรับการดูแล หรือใช้เครื่องมือที่มีบริการจัดการ
• กลยุทธ์ที่ดีที่สุดในโลกจริงมักเป็นแบบไฮบริด: ใช้ API สำหรับ ID หลักและฟิลด์พื้นฐาน แล้วใช้การสแครปเพื่อเก็บข้อมูลลึกที่ API ส่งให้ไม่ได้
• Thunderbit รองรับทั้งสองฝั่ง: Chrome Extension สำหรับผู้ใช้ no-code และ API/MCP server ที่ส่ง JSON แบบมีโครงสร้างสำหรับนักพัฒนา

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

ดึงรีวิว Google เกิน 5 รายการผ่าน Places API ได้ไหม?

ไม่ได้ Google Places API จำกัดรีวิวไว้ที่ 5 รายการต่อสถานที่ และเรียงตามความเกี่ยวข้อง ข้อจำกัดนี้มีมาตั้งแต่ API เปิดตัวและไม่เคยเปลี่ยน แม้จะมีคำขอจากนักพัฒนามานานหลายปี ถ้าต้องการรีวิวทั้งหมดของธุรกิจ การสแครป — ไม่ว่าจะทำเองหรือใช้ managed scraping API — คือทางเดียว

การสแครป Google Maps ผิดกฎหมายไหม?

ไม่มีคำตอบแบบใช่หรือไม่ใช่ที่ใช้ได้กับทุกกรณี การสแครปข้อมูล Google Maps ที่มองเห็นได้สาธารณะอาจขัดกับ Terms of Service ของ Google และการบังคับใช้มีตั้งแต่ IP block ไปจนถึงการดำเนินคดีในบางครั้งที่พบไม่บ่อย หลายธุรกิจใช้การสแครปเพื่อวิจัยภายในและวิเคราะห์คู่แข่งโดยไม่มีปัญหา Managed scraping API ช่วยลดความเสี่ยงด้านคอมพลายแอนซ์บางส่วน แต่ไม่ใช่เกราะคุ้มกันทางกฎหมาย หากคุณกำลังสร้างผลิตภัณฑ์เชิงพาณิชย์หรือประมวลผลข้อมูลส่วนบุคคล ควรปรึกษาที่ปรึกษากฎหมาย

Google Places API คิดเท่าไหร่สำหรับ 100K lookups?

ขึ้นอยู่กับฟิลด์ที่คุณขอ ถ้าเป็น Place Details ระดับ Essentials จะอยู่ราว ~$450 ถ้าเป็น Pro จะราว ~$1,615 ส่วน Enterprise + Atmosphere ซึ่งรวมรีวิวและสิ่งอำนวยความสะดวก จะราว ~$2,475 ถ้าเวิร์กโฟลว์ของคุณต้องใช้ Text Search Pro เพื่อค้นหาด้วย ให้บวกอีกประมาณ ~$3,040 ตัวเลขนี้อิง volume tiers ที่ Google เผยแพร่ และสมมติว่าคิดเงินต่อ 1 คำขอที่เสียเงิน 1 ครั้งต่อ 1 เรคคอร์ดหลังหมดโควตาฟรี

Scraping API ต่างจากเครื่องมือสแครปแบบ no-code อย่างไร?

Scraping API เช่น Thunderbit's Open API เหมาะกับนักพัฒนาที่ต้องการผสานการสแครปเข้าในโค้ด, automation pipeline หรือ workflow ของ AI agent ผ่าน HTTP request ส่วนเครื่องมือ no-code เช่น Thunderbit Chrome Extension ให้ผู้ใช้ที่ไม่ถนัดเทคนิคคลิกเลือกและส่งออกข้อมูลจากเบราว์เซอร์ได้เลยโดยไม่ต้องเขียนโค้ด ทั้งสองแบบคืนข้อมูลที่มีโครงสร้างได้ ความต่างคือหน้าตาเครื่องมือและรูปแบบการเชื่อมต่อ

Thunderbit ใช้งานกับหน้า Google Maps ได้ไหม?

ได้ Chrome Extension สามารถสแครปทั้งหน้าผลค้นหา Google Maps และหน้ารายละเอียดธุรกิจรายรายการได้ — AI จะแนะนำฟิลด์ให้อัตโนมัติ และคุณใช้ cloud mode ได้พร้อมกันสูงสุด 50 หน้า ส่วนเอ็นด์พอยต์ POST /extract ของ API ที่ตั้ง renderMode: "full" จะจัดการหน้าที่ Google Maps render ด้วย JavaScript และส่งกลับ JSON แบบตรง schema MCP server ยังช่วยให้ AI agents สแครปข้อมูล Google Maps ระหว่าง workflow ได้ด้วย

Learn More

• What Is Web Scraping
• Ai Web Scraping
• Instant Data Scraper Alternatives
• Web Scraping Without Coding
• Ai Lead Generation