Configuration Settings and Logging
The following settings are available under Stores > Settings > Configuration
Klevu > Data Sync > Order Analytics | Scope | |
|---|---|---|
Order Sync Status | [store view] | Controls whether to queue and/or send order information to Klevu’s servers. Can be overridden in CLI commands with the --ignore-sync-enabled-flag argument. |
Order Sync Frequency | [global] | The schedule used by Magento’s native cron runner to execute sync operations. If disabled, you will need to implement your own scheduled sync in order to send data to Klevu. Default: Every 5 minutes (*/5 * * * *) Note: timings are based “on the hour”, eg “Every 5 minutes” would include 00:00, 00:05, 00:10, etc |
Exclude Statuses From Sync | [store view] | Allows selection of order status(es) - including custom - in which orders will not be sent to Klevu when sync actions are performed. |
Klevu > Developer Settings > Order Analytics | Scope | |
|---|---|---|
IP Address Field for Order Data | [store view] | Which order data field to use when extracting an order’s IP address. Choose from “Remote IP” (default; uses remote_ip field) and “X Forwarded For” (uses x_forwarded_for). If your installation is sending data but it is not being included in conversion rate statistics, you may need to change this field - especially if your system sits behind WAF / CDN |
Order Sync Max Batch Size | [global] * | [global] * The maximum number of orders processed in a single CLI or cron execution. This setting is empty by default, meaning all unsent records will be attempted each time a sync is processed. Entering a value here will cause execution to exit once the configured maximum records have been attempted (starting from the earliest). You should leave this field empty unless you are encountering issues with memory or execution time, where a lower batch size and higher sync frequency may mitigate the issue. |
Order Record Max Sync Attempts | [store view] | The maximum number of times a record will attempt to sync before being classed as “failed” and removed from the sync queue. |
Consider Processing Orders Stuck After (minutes) | [global] | When stuck record processing is executed (see Sending Order Information to Klevu > Stuck Records section above), this setting is used to determine the cut off time for records. ie, if the cron runs at 10:00am, orders which transitioned to a sync status of “processing” at 9:45am or earlier (and are still processing) will be modified. |
Remove History for Successfully Synced Orders After (days) | [global] | How many days to retain sync history items for orders which have been sent to Klevu successfully. By default, all sync history will be retained. |
Remove History for Failed Synced Orders After (days) | [global] | How many days to retain sync history items for orders which sync has been attempted but failed. By default, all sync history will be retained. |
Klevu > Developer Settings > Logging | Scope | |
|---|---|---|
Analytics Log Level | [store view] | The verbosity of logging performed for actions taken by the Analytics module, or any of its children, including within pipelines. By default, this should be left as Standard or Errors Only (for established, heavily trafficked stores) to keep log sizes to a minimum. When troubleshooting, especially in non-production accounts, Verbose logging is essential; therefore, when sending debug logs to the Klevu support team, please ensure this has been updated for any / all stores encountering issues. |
Orders will continue to be queued, meaning changes to this setting or the status of the order (eg, once payment has been taken) may cause orders to be sent at a later stage. Changing this setting or the order status (eg, marking as fraud) will not affect orders already sent to Klevu.
This setting will not differentiate based on order state, for example where Suspected Fraud is assigned to both Payment Review and Processing states
As orders batches comprise records from all enabled stores, implementing a batch limit may cause some operations to exclude lower trafficked stores entirely.
This value includes the initial sync, as every order must be attempted at least once. A value of zero or lower, therefore, will be treated internally as “1”
This threshold applies to the individual history items, so orders whose processing has spanned multiple days may see partial history.
The order’s current sync status is considered during processing, meaning that even if the record failed to sync prior to a success send, this threshold will apply to all its associated history items.
This threshold applies to the individual history items, so orders whose processing has spanned multiple days may see partial history.
The order’s current sync status is considered during processing, meaning that even if the record send successfully but was re-queued and failed this threshold will apply to all its associated history items.
After changing any configuration settings, please remember to clear the Config cache.
The Analytics group of modules implement dedicated logs to segregate them from other areas, grouped by store name. These logs can be found at /var/log/klevu/[store_code]/klevu-[store_code]-analytics.log .
To control the level of detail included in analytics logs (configurable on a store-by-store basis), please use the Klevu > Developer Settings > Logging > Analytics Log Level setting.
