Saltar al contenido principal

Lectura de campañas de puntos desde GET

Esta guía está orientada al equipo de integraciones que interpreta campañas de puntos y wallet ya creadas al consultar listados desde GetAListOfScoreCampaigns (equivalente interno: GET /points) y las alinea con el ticket enviado a la Streaming API.

Alcance: campañas de puntos/wallet según el evento configurado en when: carrito (after_create_activity), triggers (slug de trigger configurado en la Company), eventos personalizados (after_create_custom_entity) o asignación directa (manual). Los challenges no forman parte de esta guía (se documentan aparte). La gramática JSON de rule_* es la misma que en descuentos salvo restricciones por when y ciclo de vida de saldo.

Índice​


Contenido de la guía​

PáginaQué cubre
Respuesta GETQuery params, metadatos, activación/caducidad, parseo JSON
Condicionesrule_conditions: AND/OR, catálogos cliente/carrito/líneas/tienda
Aplicaciónrule_application: alcance del otorgamiento en líneas
Efectosrule_effects: tipos, distribución, limits, bundle, scores[] en ticket

Modelo canónico​

CampoQué representa
rule_conditionsCondiciones de victoria: ¿cuándo puede otorgarse la campaña?
rule_applicationAplicación: ¿sobre qué líneas se calcula el otorgamiento?
rule_effectsEfecto: cuántos puntos/saldo y cómo se distribuye

Usa siempre rule_conditions, rule_application, rule_effects (no rules_* ni alias legacy). rule_application no es distribución; la distribución va en rule_effects.distribution.


Modalidades de acumulación (puntos vs wallet)​

En un programa de fidelización, Loyal Guru soporta dos formas de presentar la acumulación al customer:

ModalidadQué percibe el customerEjemplo de naming
PuntosUnidades (puntos, millas, likes, …); por defecto en la plataforma: puntos«Acumula puntos»
Wallet (dinero)Saldo monetario directo en un monedero, sin concepto de puntos«Carga saldo en tu wallet»

Internamente el motor trata ambos casos de la misma forma: el customer acumula un valor con potencial monetario. La Company elige cómo mostrarlo y operarlo en Owner App y en integraciones mediante accrual_mode (configuración de Company):

accrual_modeComportamiento
pointsTextos y flujos orientados a puntos; la Streaming API convierte y muestra en unidades de puntos según el score_exchange de la moneda.
moneyTextos y flujos orientados a wallet/dinero; la acumulación se expresa y redime en importe monetario.

El motor es uniforme; cambian la presentación y parte de la lógica de la Streaming API (acumular, mostrar, redimir). Al leer campañas desde GET, revisa currency y, si viene, accrual_mode en el ítem de data[] — ver Respuesta GET.

El detalle de cómo interpretar rule_effects.value (siempre en moneda) está en Efectos — Valor monetario de value.


Audiencia en puntos (select_customers)​

En puntos/wallet no existen campañas all_customers (masivas sin customer concreto). Para acreditar saldo hace falta un customer identificado; el motor no puede otorgar puntos «al aire» como un descuento de folleto masivo.

Valor en GET / Owner AppUso en puntos
loyaltyCustomers enrolados en el club (habitual en carrito, triggers y asignación directa).
targetedEntrega dirigida (audiencia concreta / voucher).
all_customersNo aplica en puntos — solo en descuentos.

Si ves select_customers: "all_customers" en un listado de puntos, trátalo como dato inconsistente o legacy; la configuración válida es loyalty o targeted.


Referencia por evento (when)​

Cada campaña de puntos tiene un único when. Eso determina qué efectos, distribuciones y bloques rule_* son válidos.

Eventowhen (API)EfectosDistribucionesrule_conditionsrule_applicationselect_customers
Carritoafter_create_activityLos 6 tiposLas 3 + reglas por tipoCatálogo completo (como descuentos)Líneas, costes adicionales y pagosloyalty, targeted
TriggerSlug configurado en la CompanySolo direct_valueSolo totalSin condiciones de ticketSin bloqueloyalty
Evento personalizadoafter_create_custom_entitypercentage, ratio, direct_valueSolo totalAtributos del eventoCampo numérico del eventoloyalty, targeted
Asignación directamanualSolo direct_valueSolo totalVacío obligatorioSin bloqueloyalty

Detalle de cada efecto y distribución: Efectos. Matriz ampliada y ejemplos por tipo en las mismas páginas enlazadas.


Cómo leer una campaña paso a paso​

  1. Metadatos y vigencia — id, name, active, available_from / available_to, category, currency, accrual_mode (si aplica). Ver Respuesta de GET /points.
  2. Evento (when) y audiencia — Identifica el evento (carrito, trigger, evento personalizado, asignación directa). Revisa select_customers: solo loyalty o targeted (ver Audiencia). Ver Reglas de acumulación.
  3. Condiciones de victoria — Parsea rule_conditions (string JSON). En manual, puede venir vacío: {"conditions":{"and":[]}}. Ver Condiciones.
  4. Aplicación — rule_application limita líneas; si falta, el alcance depende del when y del efecto. Ver Aplicación.
  5. Efecto — rule_effects: type, value, unit (ratio), distribution, limits, rule_group. Ver Efectos.
  6. Activación y caducidad — activation_period_type, activation_delay, expiration_period_type, availability_duration explican saldo pendiente vs disponible.
  7. Límites de victoria — once, once_limit, presupuesto — ver Límites (distinto de rule_effects.limits).

Asignación directa (manual)​

Campañas de puntos/wallet que el operador dispara sin ticket de compra. En GET se identifican con when: "manual"; el listado admite GET /points?when=manual.

Al leer una campaña de asignación directa, comprueba este perfil (creación: API de campañas):

AspectoValor habitual en manual
rule_conditionsVacío: {"conditions":{"and":[]}}
rule_effectsSolo direct_value; distribution: "total"; rule_group: false
select_customers"loyalty" (customers enrolados)
rule_applicationSuele omitirse (sin líneas de carrito)
Otorgamiento en ticketNo aplica carrito; el saldo se asigna por flujo operativo/admin, no vía scores[] de POST /activities

Checklist para integraciones​

  • GET /points con filtros correctos (when, customer_id, countries, …); ?when=manual para asignación directa.
  • Paginación: next_token_starts_after → starting_after hasta agotar data[].
  • Mapear GetAListOfScoreCampaigns a rule_conditions, rule_application, rule_effects.
  • Parsear JSON si los campos rule_* vienen serializados.
  • Validar restricciones por when con la matriz por evento (efectos, distribuciones, rule_conditions, rule_application).
  • Comprobar que select_customers no sea all_customers.
  • Con accrual_mode: points, convertir rule_effects.value (moneda) a puntos con el score_exchange de la currency de la campaña.
  • Revisar activación/caducidad antes de reportar «no acreditó».
  • En ticket: validar scores[] (otorgamiento) frente a rule_effects del GET; effects[] es para descuentos.

Páginas relacionadas​