SDK Ruby

Le client officiel Ruby de l’API LIKYLY : envoyez votre catalogue et ce que font vos visiteurs, recevez des recommandations personnalisées.

catalogue → événements → recommandations → impression → clic → achat

Installation

gem install likyly
# or in your Gemfile:
gem "likyly"

Ruby 3.0 ou plus récent. Aucune dépendance (net/http et json de la bibliothèque standard), Rails non requis. Thread-safe.

Démarrage rapide

1. Initialiser

Créez un client et réutilisez-le. Utilisez votre clé secrète côté serveur (voir Quelle clé ?).

require "likyly"

# Backend only: the secret key gives access to your catalog and your users.
likyly = Likyly::Client.new(
  api_key: ENV.fetch("LIKYLY_SECRET_KEY")
)

2. Envoyer votre catalogue

# Send your catalog once (and whenever it changes). Ids are YOUR ids: SKUs, UUIDs, Shopify gids...
likyly.items.upsert_many([
  { item_id: "SKU-1", title: "Nike Air Max", description: "Running shoe with air cushioning",
    properties: { "category" => "shoes", "brand" => "Nike", "price" => 129.9 } },
  { item_id: "SKU-2", title: "Adidas Ultraboost", description: "Responsive running shoe",
    properties: { "category" => "shoes", "brand" => "Adidas", "price" => 149 } },
  { item_id: "SKU-3", title: "Nike Pegasus", description: "Everyday running shoe",
    properties: { "category" => "shoes", "brand" => "Nike", "price" => 119 } }
])

# Users are optional: describe them if you want the profile to travel with their events.
likyly.users.upsert("user_123", properties: { "country" => "FR", "segment" => "premium" })

Les identifiants sont les vôtres : n’importe quelle chaîne (SKU-123, un UUID, gid://shopify/Product/123). properties est libre ; category et description améliorent la similarité, le reste est stocké tel quel.

3. Suivre les événements

# Tell LIKYLY what your visitors do.
likyly.events.view(user_id: "user_123", item_id: "SKU-1")

# Purchases carry an event_id: replaying the call can never count the sale twice.
likyly.events.purchase(
  event_id: "purchase_order_9281_SKU-1",
  user_id: "user_123",
  item_id: "SKU-1",
  quantity: 1,
  properties: { "price" => 129.9, "currency" => "EUR", "orderId" => "order_9281" }
)

4. Obtenir des recommandations

# Ask what to show. You never pick an algorithm: LIKYLY chooses the best strategy for what it knows.
recs = likyly.recommendations.get(user_id: "user_123", placement: "homepage", limit: 3)

puts "strategy: #{recs.strategy}"
recs.items.each { |item| puts "#{item.item_id} #{item.title}" }

Vous ne choisissez jamais d’algorithme : LIKYLY sélectionne la meilleure stratégie selon ce qu’il sait du visiteur et vous dit laquelle il a utilisée (strategy : hybrid, content, collaborative, session ou popular). Sans utilisateur, sans session et sans article, vous obtenez tout de même une réponse utile : ce qui est populaire.

5. Boucler : l’attribution

# Send the recommendation_id back: LIKYLY measures which recommendations get seen, clicked and bought.
first = recs.items.first
likyly.events.impression(user_id: "user_123", item_id: first.item_id, recommendation_id: recs.recommendation_id, placement: "homepage")
likyly.events.click(user_id: "user_123", item_id: first.item_id, recommendation_id: recs.recommendation_id, placement: "homepage")

Renvoyez l’identifiant de recommandation sur les événements suivants (impression à l’affichage, click, add_to_cart, purchase) : LIKYLY mesure ainsi quelles recommandations convertissent réellement.

Quelle clé ?

La clé publique ne peut que lire des recommandations et écrire des événements : elle peut donc être exposée. Ne mettez jamais la clé secrète dans du code livré à un navigateur ou à une application mobile.

# Where the code is exposed to visitors, use the PUBLIC key: it can only read recommendations and record events.
front = Likyly::Client.new(
  api_key: ENV.fetch("LIKYLY_PUBLIC_KEY")
)

# A visitor who is not logged in: use an anonymous session id (any string you generate and keep in a cookie).
front.events.view(session_id: "sess_abc", item_id: "SKU-2")
for_visitor = front.recommendations.get(session_id: "sess_abc", viewed_item_ids: ["SKU-2"], placement: "product_page", limit: 3)

Événements

track est le mécanisme unique ; impression, view, click, add_to_cart, remove_from_cart et purchase sont des raccourcis vers celui-ci. Les types d’événements sont des chaînes libres : utilisez les vôtres (favorite, share, video_played...) aussi librement que les officiels.

# Any string is a valid event type: track what matters to your business.
likyly.events.track("favorite", user_id: "user_123", item_id: "SKU-2", properties: { "list" => "wishlist" })

# Up to 1000 events per call, each with its own type.
likyly.events.track_many([
  { type: "view", user_id: "user_123", item_id: "SKU-3" },
  { type: "add_to_cart", user_id: "user_123", item_id: "SKU-3", quantity: 1 }
])

• Un événement porte un article et un utilisateur, une session, ou les deux (les deux relient la session anonyme à l’utilisateur une fois connecté).
• Visiteurs anonymes : générez un identifiant de session (n’importe quelle chaîne) et gardez-le dans un cookie ; aucune connexion requise.
• properties est un objet libre (prix, devise, numéro de commande...). Ses clés sont stockées telles que vous les envoyez et jamais renommées par le SDK.
• L’identifiant d’événement (clé d’idempotence) : rejouer un événement avec le même identifiant n’enregistre rien et renvoie duplicate: true. Renseignez-le sur les achats, par exemple purchase_<commande>_<article>.
• placement est un libellé libre de l’endroit où quelque chose s’est produit ou sera affiché (homepage, product_page, cart...).

Recommandations avancées

recommendations.get est la voie normale. Pour choisir vous-même la stratégie :

# Advanced Recommendations: one strategy at a time, when you want to choose.
similar = likyly.recommendations.similar(item_id: "SKU-1", limit: 3)
hybrid = likyly.recommendations.hybrid(user_id: "user_123", item_id: "SKU-1", alpha: 0.7, limit: 3)
session = likyly.recommendations.session(viewed_item_ids: %w[SKU-1 SKU-2], limit: 3)

Ces endpoints portent les identifiants dans le chemin de l’URL : un identifiant contenant / (comme gid://shopify/Product/1) ou, pour la liste de session, ,, est refusé par une erreur de validation. Utilisez alors recommendations.get, qui prend les identifiants dans le corps de la requête.

Erreurs

Les erreurs sont typées (toutes sont des Likyly::Error). Interceptez celles qui vous concernent :

Les erreurs issues de l’API portent : #status_code, #request_id, #retry_after (seconds), #body. Communiquez l’identifiant de requête lorsque vous contactez le support.

begin
  likyly.items.get("does-not-exist")
rescue Likyly::NotFoundError => e
  puts "no such item, request #{e.request_id}"
rescue Likyly::RateLimitError => e
  puts "slow down, retry in #{e.retry_after} s"
end

Tentatives et délais

Le SDK relance pour vous les échecs transitoires (2 tentatives par défaut, backoff exponentiel à partir de 0,5 s plafonné à 8 s, avec jitter complet) :

• 429 : toujours relancé, en respectant Retry-After. Un Retry-After supérieur à 60 s n’est pas attendu : l’erreur de limite de débit est renvoyée.
• 502, 503, 504, connexions coupées et délais dépassés : relancés uniquement quand rejouer l’appel est sans danger : lectures, upserts, suppressions, événements portant un identifiant d’événement, et lots dont chaque événement en a un.
• Un événement sans identifiant d’événement n’est jamais relancé après un échec ambigu : un réseau capricieux ne peut donc jamais enregistrer un achat deux fois. Renseignez l’identifiant sur les événements qui comptent et ils deviennent relançables.
• Les autres erreurs 4xx ne sont jamais relancées.

Configuration

tuned = Likyly::Client.new(
  api_key: ENV.fetch("LIKYLY_SECRET_KEY"),
  timeout: 5, # seconds per socket operation (default 10)
  max_retries: 3, # automatic retries on 429 / 502 / 503 / 504 / network errors (default 2, 0 disables)
  user_agent: "my-shop/1.4", # appended to the SDK's User-Agent
)

Chaque méthode accepte aussi les mots-clés timeout: et max_retries:.

Référence

Clé : S = clé secrète uniquement, P = clé publique ou secrète.

Les listes sont paginées avec limit et offset (la page par défaut de l’API compte 100 articles) ; le total est fourni avec la page. Les utilisateurs ont un import par lot mais pas de suppression par lot : l’API n’a pas de tel endpoint. L’import des articles est un alias de l’upsert par lot (l’import CSV est une fonction du tableau de bord).

Notes Ruby

• Rails : créez un client dans un initializer (LIKYLY = Likyly::Client.new(api_key: Rails.application.credentials.likyly_secret_key)) ; rien dans le gem ne dépend de Rails.
• Les champs sont des mots-clés en snake_case (item_id:, recommendation_id:) ; les clés de properties vous appartiennent et ne sont jamais renommées. Les résultats sont des Struct (recs.items.first.item_id).