สร้างเว็บอย่าง Wongnai กับโจทย์ล้านแปดที่ต้องแก้ (ตอนที่ 1)

ไม่ได้เขียนไปหลายเดือน คิดขึ้นมาได้ว่ามีเนื้อหาที่เตรียมไว้ซักพักแล้วแต่ยังไม่ได้แชร์ เลยขอแทรกก่อนเรื่องประวัติโปรแกรมฝึกงานใน Wongnai ที่ครั้งที่แล้วบอกว่าจะเขียนถึงก่อนแล้วกัน 😛

เป็นหัวข้อที่สองเดือนก่อนเตรียมไว้ให้ทางสมาคมโปรแกรมเมอร์ไทย (ThaiProgrammer.org) แล้วก็ได้ใช้แชร์ใน BarCamp Bangkhen 6 ด้วย ใจความสำคัญคือพูดให้เห็นว่าเวลาสร้างเว็บอย่าง Wongnai ขึ้นมามันมีโจทย์ปัญหาที่ต้องแก้หลายอย่างที่ถ้าไม่ได้ลงมือทำจริงก็อาจจะไม่ได้คิดถึง อีกเหตุผลที่นำเรื่องนี้ขึ้นมาพูดก็เพื่อตอบคำถามที่ผมโดนถามบ่อยๆ เวลาเจอเพื่อนแล้วคุยกันถึงงานที่ทีมผมทำอยู่ว่า

“พวก Dev ยังต้องทำอะไรอีกหรอ? ไม่ได้ทำเสร็จหมดแล้วหรอ”

ถ้าคำถามนี้ถามโดยคนที่ไม่ได้เรียนเกี่ยวกับ Computer Science มาก็คงไม่แปลกใจครับ แต่พอถูกถามโดยคนที่เรียนมาโดยตรงก็แปลกใจเหมือนกัน (เดาได้ว่าทีม Dev อีกหลายเว็บก็คงเจอคำถามนี้บ่อยเหมือนกัน)  entry นี้เลยจะอธิบายให้เห็นว่ามันมีอะไรบ้างที่ทำให้ต้องวุ่นกับการพัฒนาและเป็นสิ่งที่ท้าทายเราอยู่ตลอดเวลา จนเป็นที่มาว่าทำไม Wongnai จึงมองหา software engineer เก่งๆ มาร่วมทีมอยู่เรื่อยๆ

(เนื่องจากเนื้อหาค่อนข้างเยอะมาก เลยจะแบ่งเขียนเป็น 2 ตอนครับ)

 

ทำความรู้จัก Wongnai

ก่อนอื่นเลยต้องทำความรู้จักอย่างลึกซึ้งก่อนว่า Wongnai มีลักษณะยังไงก่อน เนื่องจากมันค่อนข้างที่จะแตกต่างจากเว็บไทยอีกหลายเว็บ ถ้าให้สรุปเป็นข้อๆ ว่า Wongnai มีส่วนผสมของอะไรบ้างก็จะได้เป็น 3 อย่างต่อไปนี้

  • Location-based service เป็นบริการไว้ค้นหาข้อมูลสถานที่และที่เกี่ยวข้องกับสถานที่
  • User-Generated Content Website เป็นเว็บที่เนื้อหาข้อมูลในเว็บเป็นข้อมูลที่ร่วมกันสร้างโดยผู้ใช้
  • Social Network เป็นเครือข่ายสังคม ที่ผู้ใช้สามารถติดตามผู้ใช้คนอื่น สร้าง profile ของตัวเองได้ และมี Feed ของตนเองทุกคน

ถ้าลองนึกถึงเว็บดังๆ ในไทย จะสังเกตว่าจะไม่ค่อยมีส่วนผสมแบบนี้ (ถ้าผมไม่ลืมเว็บไหนไปนะครับ) คือถ้าไม่ใช่เว็บซื้อขายของ ก็มักจะไม่เน้นการ search  แต่ถ้าเน้นเรื่อง search ก็มักจะไม่มีความเป็น Social Network ไม่มีการ Follow ผู้ใช้กันเอง, ผู้ใช้เห็นเนื้อหาเหมือนกันหมด, ไม่มีทางเลือกในการ customize​ หรือไม่มี feed ของตัวเอง และสุดท้ายคือไม่ค่อยมีข้อมูลเชิงตัวเลขจากผู้ใช้ ส่วนมากจะเป็น text จากการตอบคอมเม้นท์ในเว็บบอร์ด

Wongnai ให้ความสำคัญกับการสร้าง profile ของตัวเองผ่านการทำ action ต่างๆ มาก ทั้งการให้เรตติ้งผ่านรีวิว, โพสรูปภาพ, เช็คอิน, กดไลค์, กด bookmark รวมถึงการซื้อดีล เหตุผลก็คือเราอยากให้ข้อมูลที่เป็นประโยชน์เหล่านี้มาช่วยทำให้สมองของระบบที่สร้างขึ้นสามารถที่จะเรียนรู้และเข้าใจตัวผู้ใช้แต่ละคนได้ เพื่อนำเสนอ content ที่ตรงกับความต้องการของผู้ใช้ได้จริงๆ

ถ้าผม check-in และเขียนรีวิวร้านอาหารญี่ปุ่นในเชียงใหม่อยู่บ่อยๆ ก็อาจจะ imply ได้ว่าผมอยู่เชียงใหม่และชอบอาหารญี่ปุ่น ถ้าแสดง content ที่เกี่ยวข้องกับอาหารญี่ปุ่นหรือ content ที่อยู่ในเชียงใหม่มาให้ผมอ่านก็น่าจะตรงกับความสนใจมากกว่า content ที่เกี่ยวกับร้านจังหวัดอื่น

นอกเหนือจาก 3 ส่วนผสมที่บอกไป จริงๆ ยังมีส่วนของ commerce ที่เพิ่งเพิ่มมาใหม่ ซึ่งส่วนผสมทั้งหมดนี้ทำให้มันมีจุดที่ให้คิดเยอะเวลาสร้าง จุดที่สามารถปรับปรุงให้ดีขึ้นกว่าปัจจุบันได้อีกมาก ผมจะพยายามยกตัวอย่างกับอธิบายสิ่งที่เข้าใจได้ง่ายๆ ทีละอย่างให้เข้าใจครับ

 

Search เป็นเรื่องใหญ่

การใช้งานหลักอย่างนึงของผู้ใช้ Wongnai ก็คือ การค้นหาร้านด้วย 2 วิธีหลักๆ คือ ค้นหาด้วย keyword (keyword search) กับค้นหาร้านรอบๆ ตัว (nearby search)  การค้นหาแต่ละวิธีก็มีความยากของมัน ผมขอแยกสิ่งที่ต้องคำนึงถึงเรื่องการค้นหาออกเป็น 2 ส่วนคือ ส่วนรับ Input และส่วนการแสดงผล (Output)

1) ส่วนรับ Input

Keyword-based search

Keyword-based search เป็นสิ่งที่ทีม dev ปรับแต่งระบบอยู่เรื่อยๆ ให้มันดีขึ้น ซึ่งก็ต้องยอมรับครับว่าเรายังค้นหาไม่เก่งมาก หลายครั้งก็ได้ผลลัพธ์ที่ตัวผมเองก็ยังหงุดหงิดใจบ้าง (แต่มันก็เก่งขึ้นกว่าช่วง 1-2 ปีแรกมากพอสมควรนะ :D)

ขอเล่าย้อนไปยาวนิดนึงครับ ในตอนแรกเริ่มเว็บ Wongnai เรามีกล่อง search ให้ 1 กล่อง กับ dropdown อีก 1 อัน สำหรับพิมพ์ชื่อร้านแล้วก็สำหรับเลือกสถานที่(พื้นที่ค้นหา)ตามลำดับ เรียกได้ว่าตามเว็บต้นแบบ Yelp.com นั่นแหละ ซึ่งมันก็ง่ายดีกับระบบที่จะตีความได้ชัดเจนว่า user ต้องการค้นหาอะไรในพื้นที่ไหน

มีทั้งกล่องสำหรับใส่ keyword และระบุสถานที่

มีทั้งกล่องสำหรับใส่ keyword และระบุสถานที่

แต่ต่อมาเรารู้สึกว่ามันใช้ยาก แล้วก็มีข้อเสียพอสมควร เช่น

  • คนไทยคุ้นเคยกับการค้นหาด้วย Google ที่มีกล่อง search กล่องเดียว พิมพ์ในกล่อง search แล้วกด Enter ทันที หาได้ทุกอย่าง การเพิ่ม dropdown มาอันนึง เราต้องมั่นใจว่า user เห็นหรือรับรู้ว่า dropdown นั้นมันมีอยู่และมีผลกับผลลัพธ์การค้นหา ก่อนที่จะกด Enter เพื่อเริ่มการค้นหา
  • พอมี Dropdown ให้เลือก Location เราก็ต้องมาคิดอีกว่า
    • ถ้าไม่มีค่า default ให้ก่อน ก็จะเกิดกรณีที่ user พิมพ์คำค้นหาเสร็จแล้วกด Enter ทันที (ไม่สนใจ dropdown)  การค้นหาก็จะกว้างมากๆ กลายเป็นค้นหาร้านทั้งหมดในระบบแทนที่จะรู้ scope การค้นหาที่แคบลง
    • ถ้ามีค่า default — สมมติค่า default เป็น “กรุงเทพฯ” ก็ต้องมาดูกันว่า user ในจังหวัดอื่นๆ จะเห็น dropdown อันนี้แล้วกดเปลี่ยนมั้ย
    • ถ้าใช้ Location Services ของ Web Browser ในการ detect location และให้อัพเดทค่าทุกครั้งที่เข้าใช้งาน ก็ดูจะเข้าท่ามากกว่าแบบอื่น แต่ถ้าเกิดวันนึงผู้ใช้ต้องการค้นหาร้านในจังหวัดที่ตัวเองไม่ได้อยู่ ก็อาจจะเกิดปัญหา เพราะไม่เคยสัมผัส dropdown ที่ไว้เลือกจังหวัดด้วยตัวเองมาก่อน

สังเกตว่าการมี dropdown ไม่ว่าจะกรณีไหนก็ตาม มันจะเจอปัญหาเดียวกันหมดคือ ผู้ใช้อาจจะไม่เคยแตะ dropdown ที่อยู่ข้างๆ มาก่อนเลย ไม่เคยเลือกค่าใน dropdown ให้ตรงกับสิ่งที่ต้องการค้นหา ทำให้กลายเป็นใช้ค่า location ที่ผิดๆ   ผลลัพธ์การค้นหาก็พลาดไป เพราะมันผิดตั้งแต่ input แล้ว

บางคนอาจจะบอกว่าปัญหาแบบนี้มันสามารถแก้ได้ด้วยการปรับปรุง UI/UX ให้ดี เพื่อทำให้ผู้ใช้ใส่ input ไม่ผิด (ไม่ลืมว่าต้องใส่, ไม่ลืมว่าเคยใส่แล้ว, ไม่ลืมที่จะเปลี่ยนใหม่) ได้  ซึ่งผมว่าก็เป็นไปได้นะ  แต่สุดท้ายแล้ว เราเลือกที่จะเปลี่ยนมาเป็นกล่อง Search กล่องเดียว ด้วยเหตุผลเรื่องความง่ายในการใช้งานของผู้ใช้ (ด้วยความคุ้นเคยกับการใช้ Google)

 

Single search box

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

ต้องยอมรับครับว่าช่วงแรกที่เปลี่ยนมาเป็นกล่อง search กล่องเดียว เราลืมคิดไปเหมือนกันว่าผู้ใช้จะพิมพ์ทุกอย่าง (ทั้งที่ช่วงแรกๆ เราใส่ hint เพื่อบอกว่าให้ใส่ชื่อร้านก็ตาม) จนกระทั่งเราได้เข้าไปดูใน analytics เพื่อดูว่า keyword อะไรบ้างที่ถูกค้นหาบ่อย ก็เลยเจอว่าผู้ใช้พิมพ์กันแบบอิสระมาก

Single search box

กล่อง Search กล่องเดียวต้องค้นให้ได้หมดทุกอย่าง

ยกตัวอย่างคำค้นหาที่เราควรจะต้องวิเคราะห์ให้ดีว่าผู้ใช้กำลังค้นหาอะไร

  • พิมพ์ “บ้านไอซ์” น่าจะอยากค้นหาร้านที่ชื่อว่า บ้านไอซ์
  • พิมพ์ “พารากอน” ก็น่าจะหาร้านใน Siam Paragon
  • พิมพ์ “ภูเก็ต” น่าจะหมายถึงค้นหาร้านในภูเก็ต ไม่ใช่ค้นหาร้านที่ชื่อภูเก็ต
  • พิมพ์ “ซีฟู้ด” น่าจะหมายถึงค้นหาร้านอาหารทะเล
  • พิมพ์ “คั่วกลิ้ง” ก็อาจจะหมายถึงค้นหาร้านที่มีเมนูคั่วกลิ้งก็ได้
  • พิมพ์ “Spa” ก็น่าจะหมายถึงค้นหาร้านที่เป็นร้านประเภท Spa

คำที่ยกตัวอย่างข้างบนนี้น่าจะตรงไปตรงมาครับ แต่ลองดูตัวอย่างคำต่อไปนี้ครับ

  • พิมพ์ “ภูเก็ตซีฟู้ด”  อ้าวๆ ชัวร์สิครับว่าเค้าต้องหาร้านซีฟู้ดในจังหวัดภูเก็ต แค่ filter ร้านอาหารทะเลที่อยู่ในภูเก็ตก่อนเลยก็น่าจะโอเคแล้ว  แต่! ปรากฎว่าในไทยเรามีร้านที่ชื่อว่า “ภูเก็ตซีฟู้ด” ที่ไม่ได้อยู่ในภูเก็ตเนี่ยสิ ฮ่าๆ
  • พิมพ์ “Spa Food” คำนี้อาจจะไม่ยาก ถ้าข้อมูลในระบบมีแค่ร้านอาหารอย่างเดียว แต่ใน Wongnai เรามีร้านที่เกี่ยวกับ Beauty อยู่ด้วย  ถ้าวิเคราะห์จาก keyword เราอาจจะคิดว่าผู้ใช้กำลังค้นหาร้าน Spa ที่มีคำว่า Food ด้วย แต่! ความจริงคือ มีร้านที่ชื่อ Spa Food ที่เป็นร้านอาหารอยู่ครับ  ถ้าเราไป filter ร้าน Spa ก็อาจจะร้านไม่เจอทันที

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

 

ภาษาไทยกับคำทับศัพท์

ลองนึกถึงสถานการณ์ต่อไปนี้ครับ

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

B: เดินผ่านร้านชื่อ “Calin” อ่านในใจว่า “คาลิน” (จริงๆ แล้วต้องอ่านว่า “กาแล็ง”) แล้วเกิดอยากอ่านรีวิวร้านนี้

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

สิ่งที่ต้องการจะสื่อก็คือ ผู้ใช้ค้นหาทั้งภาษาอังกฤษและภาษาไทย และมีโอกาสเป็นภาษาไทยเยอะด้วย ดังนั้นระบบค้นหาก็ควรจะเก่งพอจะค้นหาผลลัพธ์ได้แม้ว่า user จะสะกดชื่อร้านผิดพลาดบ้างนิดๆ หน่อยๆ หรืออาจจะใช้ suggestion มาช่วยไกด์ให้ user เดินไปถูกทางว่าควรจะพิมพ์ตัวอักษรอะไรเป็นตัวต่อไป

 

Nearby search

การพิมพ์คำค้นหาร้านก็ว่ายากแล้วที่จะหาคำตอบให้ตรงใจ การค้นหาร้านโดยไม่ป้อนคำอะไรเลยก็ไม่ใช่เรื่องง่ายครับ  ผมกำลังจะพูดถึงการค้นหาอีกวิธีนึงที่บอกไว้ก่อนหน้านี้ นั่นก็คือ ค้นหาร้านรอบตัว (nearby search) ครับ

การค้นหาร้านใกล้ตัว เป็นหนึ่งในฟีเจอร์ที่ผู้ใช้แอพ Wongnai ใช้กันเยอะมาก เพราะมีโอกาสได้ใช้ค่อนข้างบ่อยเวลาไปในพื้นที่ที่ไม่รู้จัก เนื่องจากเราสามารถใช้ GPS ที่มากับ Smart Phone เป็นตัวช่วยค้นหาร้านรอบตัวได้

ค้นหาร้านอาหารรอบๆ ตัว

ค้นหาร้านอาหารรอบๆ ตัว

การค้นหาร้านรอบตัวนั้นแน่นอนว่าเราต้องพิจารณาถึงระยะทางและ/หรือขอบเขต ถ้าให้คิดวิธีค้นหาร้านใกล้ตัวอย่างตรงไปตรงมาสุดๆ ก็คือวาดรัศมีออกไป X เมตร แล้วก็หาร้านในฐานข้อมูลเราว่ามีร้านไหนบ้างที่อยู่ภายในวงกลมก็เป็นอันจบ แต่ความจริงมันไม่ง่ายอย่างงั้น ด้วยเหตุผลที่ว่า

  • “ร้านใกล้ตัว” ที่ผู้ใช้ต้องการ จริงๆ แล้วต้องบอกว่า “ร้านดีๆ ใกล้ตัว” มากกว่า
  • แล้วเราจะรู้ได้ไงว่าร้านดีๆ อยู่ห่างออกไปเท่าไหร่
  • แล้วอะไรคือเรียกว่าใกล้?

“ใกล้”

จริงๆ ร้านดีๆ มันพอจะมีตัวชี้วัดระดับนึง (เช่นจาก average rating) แต่คำว่าใกล้นี่ก็ยากไม่ใช่เล่น เพราะนิยามของคำว่า “ใกล้” มันขึ้นกับ context ด้วย โดยเฉพาะสถานที่ ยกตัวอย่างเช่น

  • ถ้าเรายืนอยู่แถวสยามสแควร์  ร้านที่อยู่แถวชิดลมที่ห่างออกไปประมาณ 1 กิโลเมตร (มั้ง) ก็คงไม่เรียกว่าใกล้
  • ถ้าเราอยู่ต่างจังหวัด ถ้าร้านดีๆ อยู่ห่างออกไปซัก 5 กิโลเมตร ก็ถือว่าใกล้ได้ เพราะในต่างจังหวัด รถไม่ติดมากเท่า เรายินดีที่จะขับรถออกไปเพื่อให้ได้เจอร้านดีๆ

จะเห็นว่านิยามคำว่า “ใกล้” มันต่างกันไปในแต่ละ location มันมีเรื่องความลำบากในการเดินทางมาเกี่ยวข้องด้วย (ไม่ว่าจะเป็นจราจร, สภาพภูมิประเทศ ฯลฯ)

นี่ก็เป็นอีกสิ่งหนึ่งที่ทีม Dev ต้องคิดเยอะหาวิธีเพื่อให้ผลลัพธ์ออกมาเข้าท่ามากที่สุด ซึ่งปัจจุบันเราก็ทำได้ดีระดับนึง แต่ก็ยังสามารถทำให้ดีกว่านี้ได้อีก เราปรับ algorithm อยู่เป็นระยะๆ ครับถ้าเริ่มสังเกตเห็นผลลัพธ์ที่ยังไม่พอใจ

 

2) ส่วนการแสดงผล

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

สำหรับเรื่อง UI ผมคงไม่พูดถึงครับ แต่จะขอพูดในส่วนของการเรียงลำดับผล search ซึ่งมาจากการให้คะแนนว่าของสิ่งไหนได้คะแนนความใกล้เคียงกับสิ่งที่ผู้ใช้กำลังค้นหามากที่สุด ซึ่งไอ้การคิดคะแนนนี่แหละที่ยุ่งยากสุดยอด คำถามจะเกิดในหัวมากมายครับ ยกตัวอย่างเช่น

  • ปัจจัยอะไรบ้าง ข้อมูลสถิติตัวไหนบ้างที่จะนำมาคิดเป็นคะแนนให้กับร้าน แล้วตัวเลขตัวไหนที่จะ weight หนัก/เบากว่ากัน
  • ร้านที่รีวิวเยอะดาวเยอะ แต่ว่าไม่ฮิตแล้วในปัจจุบัน ควรจะอันดับดีเหมือนเดิมไปเรื่อยๆ หรือไม่
  • ร้านหรูราคาแพงๆ ที่มักจะเป็นร้านที่คุณภาพดีก็เยอะ แต่โดยธรรมชาติแล้ว ร้านประเภทนี้ก็มักจะมีรีวิวน้อย เพราะคนไปกินน้อย ทำยังไงให้ร้านที่รีวิวน้อยแต่เรตติ้งดี มีโอกาสออกสู่สายตาผู้ใช้
  • ร้านที่ดาวเท่ากัน แต่ร้านนึงมีผู้ใช้ที่ rank สูงกว่าเขียนเยอะ กับอีกร้านที่ส่วนใหญ่รีวิวมาจากผู้ใช้หน้าใหม่ ร้านไหนควรขึ้นก่อน?
  • ร้านที่อยู่ใกล้ผู้ใช้มากๆ กับร้านที่อยู่ไกลออกไปแต่ว่าได้เรตติ้งดีกว่า ร้านไหนควรขึ้นก่อน?

สุดท้ายแล้วเราก็จะได้สูตรการคำนวณ หรือ algorithm ในการคิดคะแนนที่ค่อนข้างซับซ้อน และก็ต้องคอยปรับจูนอยู่เรื่อยๆ เมื่อเจอว่าผลการค้นหายังไม่ถูกใจ หรือยังมีจุดบอดที่ทำให้ได้ผลลัพธ์ไม่ดี   (สำหรับ Wongnai ก็มีการปรับ algorithm อยู่เรื่อยๆ ครับ)

 

Web Performance

เว็บช้า ผู้ใช้คงไม่ปลื้มแน่   performance ของเว็บเป็นสิ่งที่เว็บทุกเว็บให้ความสำคัญมาก เทคนิคในการ optimize เว็บมีเยอะแยะเต็มไปหมด แต่เทคนิคยอดฮิตขั้นพื้นฐานเลยก็คงจะเป็นเรื่องการ cache ข้อมูลที่มีการเปลี่ยนแปลงน้อยแต่กว่าจะได้คำตอบมาต้องเสียเวลานานเอาไว้  แต่กับเว็บที่ content ในเว็บมัน dynamic มาก โดยเฉพาะเว็บที่ content สร้างโดยผู้ใช้ (User-generated content) แล้วก็เป็น Social Network ด้วยอย่าง Wongnai การ cache ข้อมูลไว้ก็เป็นเรื่องที่ยากขึ้นด้วยปัจจัยหลายๆ อย่าง

การทำ index สำหรับระบบ search ก็เป็นอีกวิธี optimize เว็บให้ค้นหาของได้รวดเร็วขึ้น แต่เราก็ไม่ได้สามารถทำ index ได้ทุกอย่างอยู่ดี เพราะการใช้งานของผู้ใช้ Wongnai ไม่ได้เป็นแค่การ browse หน้าเว็บไปเรื่อยๆ  แต่เป็นการค้นหาทั้งจาก keyword และค้นหาตาม location

ถ้าเป็นการค้นหาด้วย keyword เราอาจจะสามารถทำ index ล่วงหน้าหรือ cache ผลลัพธ์การค้นหาไว้ได้ระดับหนึ่ง แต่การค้นหาร้านรอบตัวด้วย location (latitude, longitude) โอกาสที่เราจะคำนวณหาคำตอบไว้ล่วงหน้านั้นเป็นไปไม่ได้เลยหรือเป็นไปได้ยากส์ เพราะผู้ใช้แต่ละคน request ข้อมูลจากตำแหน่งที่ต่างกัน แค่ยืนห่างกัน 10-20 เมตร ก็อาจจะได้ผลลัพธ์ต่างกันแล้ว นี่ขนาดยังไม่ได้นึกถึงความสามารถต่อๆ ไปที่จะทำเรื่อง personalized search ด้วย การทำ index ยิ่งเป็นไปได้ยากขึ้นไปอีก (caching ก็เช่นกัน)

 

SEO

คงไม่ต้องปฏิเสธเลยว่า Traffic ของเว็บ content ส่วนใหญ่ จะมาจาก Search Engine อย่าง Google   แต่ละเว็บก็พยายามที่ดัก traffic จากตรงนี้และพยายามทำให้หน้าเว็บของตัวเองติดอยู่ในผลการค้นหาของ Google เป็นอันดับแรกๆ เมื่อผู้ใช้ google ค้นหาข้อมูลด้วย keyword ที่ตรงกับ content ที่มีในเว็บ

จำนวน keyword ที่แต่ละเว็บต้องการดักจับ traffic ก็แตกต่างกันไป อาจจะมีจำนวนหลักสิบ หลักร้อย แต่ถ้าเป็นเว็บประเภท Commerce ที่ไว้ค้นหาสินค้า หรือเว็บที่ไว้ค้นหาสถานที่อย่าง Wongnai  ปริมาณ keyword มันก็จะเป็นสเกลที่ใหญ่ขึ้นหน่อย เพราะมีหน้าแสดงข้อมูลจำนวนมาก  ถ้าพูดถึง Wongnai.com ก็มีหน้าที่ไว้แสดงสถานที่ในระบบจำนวนมาก (เกือบ 200,000 สถานที่) ซึ่งก็หมายความว่าเรามี keyword ที่อยากจะให้ Google ค้นหาเจอในอันดับต้นๆ จำนวนหลักแสนคำ

การจะทำโครงสร้างเว็บให้ถูกหลักและถูกใจ Google เวลามา crawl ข้อมูลเราไปก็เป็นอีกเรื่องใหญ่สำหรับเว็บที่มี content ปริมาณมาก  คนที่เชี่ยวชาญด้าน SEO ที่เคยดัน keyword จำนวนไม่มากให้ติดอันดับใน Google อาจจะตกม้าตายได้เมื่อต้องมา optimize เว็บสเกลนี้ถ้าไม่วิเคราะห์กันให้ลึกสุดๆ และก็ต้องทำงานร่วมกับทีม Dev เพื่อปรับเปลี่ยนให้ทันเหตุการณ์อยู่เรื่อยๆ เวลา Google search มีการเปลี่ยนแปลง  ทีม Dev ก็ต้องพร้อมที่จะปรับเปลี่ยนตามคำแนะนำของคนที่ดูแลเรื่อง SEO อยู่ตลอด

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

 

ทิ้งท้ายตอนแรก

มาถึงตรงนี้ คนที่เคยสงสัยว่าทีม Dev ของ Wongnai ยังต้องทำอะไรอยู่อีก น่าจะพอได้รับคำตอบไปพอสมควรนะครับ น่าจะได้เห็นถึงปัญหาต่างๆ ที่ทีมงานต้องคอยแก้ คอยปรับปรุงเพื่อให้ผู้ใช้ทั้งเว็บและแอพ Wongnai พอใจกับการใช้งานให้มากขึ้น

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

  • Full-stack Web Developer
  • Android Developer
  • iOS Developer
  • QA Automation Engineer
  • SEO Analyst
  • IT Support
  • Digital Marketing
  • Graphics Designer

ส่ง resume มาที่ recruit@wongnai.com

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

สำหรับตอนแรกนี้ขอจบเพียบเท่านี้ก่อนครับ  ขอไปพักชาร์จพลังเตรียมเขียนเนื้อหาตอนต่อไปซักยาวๆ อีกซักรอบครับ 😀

Advertisements

2 comments

  1. konicabook · January 19, 2016

    Reblogged this on Konicablog and commented:
    ควรอ่าน

  2. cecilguy90605 · April 8, 2016

    HOLA AMIGO, ME GUSTARIA SABER I PUEDO CORRER EL OPERA EN UN NOKIA 5700, YA QUE HE INTENTADO HACERLO VARIAS VECES PERO ME INDICA QUE HAY UN ERROR Y DEB Click https://twitter.com/moooker1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s