Configuration Settings and Logging

configuration settings 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 logging 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