← Όλες οι διασυνδέσεις Eshop

Η ροή με μια ματιά

  1. Έλεγχος Merchant Center και πηγών
  2. Χαρτογράφηση προϊόντων και παραλλαγών
  3. Υποβολή πιλοτικών δεδομένων
  4. Παρακολούθηση τελικής επεξεργασίας

Τι χρειαζόμαστε πριν την υλοποίηση

  • Λογαριασμός Merchant Center και κατάλληλα δικαιώματα
  • Cloud project και σύνδεση developer όπου χρειάζεται
  • Συνεπή αναγνωριστικά και σελίδες προϊόντων
  • Συμφωνημένη πηγή τιμών και αποθέματος
1)

Με μια ματιά

Η σύνδεση Google Merchant Center μεταφέρει τον κατάλογο του Eshop σε δομημένη πηγή δεδομένων για την παρουσία προϊόντων στο Google. Δεν αποτελεί εισαγωγή παραγγελιών από γενικό marketplace. Το έργο εστιάζει σε σταθερά IDs, ακριβείς τιμές, διαθεσιμότητα και έλεγχο του τελικού επεξεργασμένου προϊόντος. Η τεχνική σύνδεση δεν εγγυάται προβολή, κατάταξη ή αποδοχή κάθε είδους.

2)

Feed ή API με βάση την πραγματική ανάγκη

Η επιλογή εξαρτάται από τον κατάλογο, τον ρυθμό αλλαγών και την υποδομή του καταστήματος. Ένα προγραμματισμένο αρχείο μπορεί να καλύπτει απλούστερη ροή, ενώ το Merchant API επιτρέπει προγραμματισμένη διαχείριση δεδομένων. Δεν αλλάζουμε μέθοδο μόνο επειδή η API φαίνεται πιο σύγχρονη. Εξετάζουμε ποιο σύστημα θα συντηρεί τα πεδία και πώς θα εντοπίζει η ομάδα τις αποτυχημένες ενημερώσεις.

3)

Η πηγή δεδομένων έχει σημασία

Η επίσημη API διακρίνει δεδομένα υποβολής από το τελικό επεξεργασμένο προϊόν. Η ενημέρωση μέσω API αφορά κατάλληλες API data sources και δεν αντικαθιστά αυθαίρετα προϊόντα πηγής αρχείου. Σχεδιάζουμε τις πηγές από την αρχή ώστε να αποφεύγονται διπλές ή αντικρουόμενες ενημερώσεις. Γλώσσα, feed label και offer ID συμμετέχουν στην ταυτοποίηση, επομένως η αλλαγή τους χρειάζεται ελεγχόμενη μετάβαση.

4)

Ακρίβεια μεταξύ καταλόγου και σελίδας

Ο τίτλος, η εικόνα, η τιμή και η διαθεσιμότητα πρέπει να συμφωνούν με τη σελίδα προορισμού. Τα τεχνικά χαρακτηριστικά προέρχονται από πραγματικά στοιχεία και οι παραλλαγές έχουν σαφή αντιστοίχιση. Ελέγχουμε ειδικά το προϊόν που ανοίγει όταν ο επισκέπτης ακολουθεί το URL. Μια γενική σελίδα οικογένειας με διαφορετική αρχική τιμή μπορεί να δημιουργήσει ασυμφωνία ακόμη κι αν το αρχείο είναι συντακτικά σωστό.

5)

Παράδειγμα καταστήματος με συχνές μεταβολές τιμών

Ένα κατάστημα ηλεκτρονικών ενημερώνει τιμές από το ERP αρκετές φορές την ημέρα. Η γέφυρα παρακολουθεί τις πραγματικές μεταβολές, κρατά σταθερά IDs και στέλνει μόνο την τρέχουσα πληροφορία προς την επιλεγμένη πηγή. Μετά την υποβολή ελέγχει την τελική επεξεργασμένη κατάσταση και εμφανίζει εκκρεμότητες. Η εμπορική ομάδα μπορεί να διορθώσει αναγνωριστικά ή εικόνες από αναφορά ανά προϊόν. Το παράδειγμα αφορά οργανωμένη διαχείριση δεδομένων, όχι υπόσχεση ότι η ενημέρωση εμφανίζεται ακαριαία ή αυξάνει από μόνη της τις πωλήσεις.

6)

Αποδοχή με έλεγχο επεξεργασίας

Δοκιμάζουμε αλλαγές τιμής και διαθεσιμότητας, διαγραφή προϊόντος που έπαψε να πωλείται και επανάληψη μετά από προσωρινή αποτυχία. Η απάντηση υποβολής δεν είναι το τελικό κριτήριο επιτυχίας: παρακολουθούμε τα processed products και τις ενδείξεις προβλημάτων. Ο λογαριασμός Merchant Center, το Cloud project και τα δικαιώματα πρόσβασης πρέπει να έχουν καταγεγραμμένη ιδιοκτησία. Η τακτική ανανέωση παραμένει λειτουργική υποχρέωση και μετά την παράδοση.

Έλεγχοι αποδοχής πριν τη λειτουργία

  • Συμφωνία δεδομένων με το landing page
  • Έλεγχος processed product και προβλημάτων
  • Ενημέρωση χωρίς διπλές πηγές
  • Ορατή αποτυχία τακτικής ανανέωσης

ΑΠΟ ΤΟΝ ΟΔΗΓΟ ΣΤΗΝ ΠΡΑΞΗ

Ένα συγκεκριμένο πλάνο για την πλατφόρμα σας.

Πείτε μας πού δυσκολεύεται η πλατφόρμα σας και τι χρειάζεται να βελτιωθεί. Η ομάδα μας συνδέει τη διάγνωση με συγκεκριμένες εργασίες σε κώδικα, απόδοση και υποδομή.

Ας δούμε την πλατφόρμα σας

Πηγές και επιπλέον ανάγνωση