További bejegyzések
Ez a bejegyzés még ezeken a nyelveken is olvasható: magyar
In this latest Hammy release we introduce traffic contol which enables an exact definition of send time window and the corresponding send speed. A new statistics interface has been implemented on the server side. We refactored the management of system parameters and improved the stability of the search interface and the validation of variables in templates. A further sophistication of channel management is introduced, i.e. individual parameters can now be used to define the communication channel. As usual, the release contains some minor fixes and improvements.
Release number 3.20.11
Date of release November 2020
Batch sending is an existing feature of Hammy Digital Direct Marketing (DDM). It allows the user to regulate the volume of messages and the send time interval in a campaign. This functionality has now been extended and made available generally, for all channels and all send processes.
The aim of the regulated batch sending is to avoid flooding the customer base with a large message volume, thereby prevent an overload in other parts of the value chain, for example in customer service.
Traffic can be regulated based on templates, template groups of even globally, for all messages. There are two regulatory parameters required, send time window and send speed. The time window defines the periods when messages can be sent. This can be defined at the minute level. The send speed governs the maximum number of messages to be sent per hour. In case an excessive send request is received, the excess messages are parked. Such messages will have the status of 'REGULATED', allowing easy separation and filtering through the HammyAdmin interface.
The previously existing API has become outdated, it no longer corresponded to reporting requirements for the growing wealth of functionality. The service access point has now been redsigned. New Statistics tables have been added in the Hammy database and new aggregation dimensions have been added. These are: scenario naem, campaign send ID, campaign ID, statistic type, statistic code, channel and aggregation time period.
The server side implementation is now in place for the internal processes and the API. The next step is developing the administator's interface to be able to best present and make use of the data garnered through the API.
Omni-channel sending is a core feature of Hammy. It can be configured at multiple levels, since the request received by the service point contains the definition of the channel. The default channel to be used can be defined among the system parameters, at the template or template group level as well.
It is an additional requirement for available metadata to override the send channel. A good example for this, in the case of e-mail, is the address domain of the recipient. Encrypted e-mail of general e-mail may be sent, both of which correspond to separate channels in Hammy. The framework for this metadata-driven channel selection has now been implemented and the first implemented use case is the domain-based channel selection. Later this same framework will allow for an easy implementation of sending the optimal services providerr for SMS text messages. By selecting the home/native service provider for the mobile number (if available), communication costs can be optimised.
'System parameters' on the HammyAdmin interface is an essential component of configuring Hammy operations. All important parameters can be set and tuned here. System parameters can be set in multiple spots in the HammyAdmin, e.g. on the Control Panel or in Templates.
This presentation and functionality of was burdened by legacy design of the UI as well as the server side service point. It has now been refactored in the new Hammy release. Server side functionality has been expanded and a new interface for the management by the user is provided in HammyAdmin.
It is a long standing feature of Hammy to enrich the message templates with variable data such as customer name and contract or policy number. However, these parameters must adhere to strict formal requirements which may pose issues for the user. If the variable references of the template are incorrect, the error may surge only later, in the production process.
In order to avoid such late issues, a new validation has been introduced at the time of editing. Variable errors are now detected and the user is notified at during the editiing work.
The query interface allows the user to gain detailed information on the status of messages as well as other message parameters. As the active database is being searched, the queries provide an extra workload for the system which may result in a performance dip. This is especially prevalent in the case of multiple quieries running at the same time. This has now been limited, to maintain stability. Multiple queries can still be started but a queue system has been introduced. This guarantees that each query will produce the result for the user in subsequent fashion while system stability is also maintained.
Scenarios drive the communication process corresponding to individual user behavior. Starting fromg this new release of Hammy, scenarios are presented on a screen where pages can be turned, allowing easier access to them for overviewing and editing.
A bejegyzés teljes szövege a medium.com-on olvashatóTovábbi bejegyzések