This application relates generally to providing and managing email content and more specifically to dynamically rebuilding content of emails sent out to recipients.
Emails are sent out by communication systems for several purposes such as notification, acknowledgement, authorization, etc. When an email is sent to a specific entity, the email is usually personalized by including the name of the person, address, the type of correspondence, and correspondence details. When the email is sent to a large list of recipient email addresses, as in a marketing campaign, the email is generated using an email template. In order to personalize the email for each of the recipient email addresses, certain portions of the email template is configured as dynamic portions while the other portions of the email template remain static. The dynamic portions of the template are populated with values (e.g., values for name, address, etc.) personal to each recipient email address prior to distribution.
However, owing to the large volume of the mass distributed emails, storing a copy of all the sent emails in a communication system would require a lot of storage space in a database table in addition to lowering system performance. This problem is further magnified if the communication system operates in hosted environments such as OnDemand solutions which do not provide for storing entails in mass data processes.
Various embodiments of systems and methods for dynamically rebuilding content of, ent out emails are described herein. In an aspect, the method involves receiving a request to review/check/display a content of a personalized email sent to a particular recipient of a plurality of recipients. The plurality of recipients being members of a target group of recipients. Further, the method involves accessing an outbound email tracking table having individual tracking record for each recipient. The tracking table holds a mapping of the plurality of recipients to specific versions of an email template. The email template outlines the content of the personalized email sent to the respective one of the plurality of recipients and includes place holders for receiving variables specific to each recipient. In another aspect, based on the mapping, a specific version of the email template applied in creating the email sent to the particular recipient is retrieved from a repository. In yet another aspect, the content of the email sent to the particular recipient is rebuilt by replacing the place holders in the retrieved email with variables specific to the particular recipient. The rebuilt email content is then rendered on an output interface, e.g., a display.
These and other benefits and features of embodiments-will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for dynamically rebuilding content of sent out emails are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Software as a service (SaaS) sometimes referred to as “on-demand software” is a software delivery model in which software and associated data are centrally hosted on the cloud. SaaS is typically accessed by users using a thin client via a web browser. SaaS has become a common delivery model for many business applications, including accounting, collaboration, customer relationship management (CRM), management information systems (MIS), enterprise resource planning (ERP), etc. SaaS applications are hosted centrally where software and data are stored on host servers. The applications can be run on a PC with an interact connection and a web browser. One such SaaS offering is SAP Business ByDesign from SAP AG.
The SAP Business ByDesign solution offers several modules designed to track end-to-end business processes. For example, Customer relationship management (CRM) is one such module designed to support processes that span marketing, sales and service activities, Marketing includes a variety of activities such as creating and running marketing campaigns across multiple channels, connecting with target customers, generating leads, etc. One of the marketing functions supported by SAP CRM module is campaign management to control the complete marketing campaign processes including design, execution, coordination, optimization, and monitoring.
Release FP4.0 of SAP Business ByDesign solution provides for the use of email templates for generating an email. The email templates have a pre-defined text including place holders for receiving personal data pertaining to a recipient. In an aspect, the email templates are created at an external source (3rd party) using state-of-the-art tools as a file and uploaded into the GRIM system. A marketing campaign would typically send several hundreds of personalized emails to recipients. However, the display/check of the sent email content is usually done only for a few of the sent personalized emails. Having been created from a common email template, the sent personalized emails are nearly identical, differing only in the place holder values. Therefore storing a copy of the entire content of each personalized email that is sent would consume a large storage space in the corresponding database table. In order to reduce the stored data to a minimum, only that information that is needed to rebuild the sent personalized email upon request is stored in the database table. The system environment for executing a marketing campaign is described with reference to a block diagram shown in
In some instances, one or more client devices may be associated with administrators of the environment, and may be capable of accessing and interacting with the settings and operations of one or more business applications, and/or other components of the illustrated environment 100. Additionally, there may also be one or more additional client devices external to the illustrated portion of environment 100 capable of interacting with the environment 100 via network 140. Further, the terms “client” and “user” “personnel” may be used interchangeably as appropriate and refer to a person or entity. Moreover, while the client device 120 is described in terms of being used by a single user, this disclosure contemplates that many users may use one computer, or that one user may use multiple computers. For example, several employees of a client company, called users, can use the applications deployed on the corresponding client device. For instance, the term “client device” refers to a system providing a set of business applications belonging to or rented by a particular customer or business entity. Several employees of that particular customer or business entity can be users of that client device and use the business applications provided by or available on this client device.
The environment 100 is an example and, in alternative implementations, the elements illustrated in
In an embodiment, the user(s) of the client device 120 creates a new marketing campaign for sending personalized emails to the members of an assigned target group. The creation of a new marketing campaign is part of a campaign definition phase in which an email template (a HyperText markup language (HTML) email form) for generating the personalized mails is created at the client device 120. In an aspect, the template is created external to the environment 100 by 3rd party tools. The externally created email template is then uploaded into the campaign management module 112 and assigned to a specific campaign. Email templates are the basis on which e-mails, letters, electronic messages like SMS, and faxes are generated and sent to members of a target group. The content of the email template can be personalized by adding personal data relating to the customer into designated place holders in the template. In an aspect, the creation and maintenance of email template is streamlined to provide more Marketing-related features. For example, you can create personalized mail using HTML email and include graphics, and Uniform Resource Locators (URLs).
After the campaign definition phase is complete, the execution of the campaign is scheduled at the client device 120 by creating a new MDRO run. In an embodiment, in order to schedule the execution of the created campaign, the user activates an “Execute” option provided on a UI of the client device 120 is activated. In response to receiving the activation of the “Execute” option, the MDRO Campaign Execution module 115 calls a CREATE_EXECUTION_RUN action in a campaign node “EXECUTION_STEP.” The CREATE_EXECUTION_RUN action creates a new instance of MDRO CampaignExecutionRun. Subsequently, the UI opens a modal window on the client device 120 where the created MDRO instance can be scheduled for immediate run or execution at a future date/time. Once the campaign execution is scheduled the campaign status is set to “Active.” The campaign is then executed at the scheduled time. As used herein, a Mass Data Run Object (MDRO) executes an automatic mass processing of a business transaction, for example, the processing of a campaign execution for sending mass personalized entails.
During the execution phase, the MDRO reads all the members in the target group of recipients, and provides the member data to the campaign management module 112. Using the member data, the EXECUTE action of the EXECUTION— STEP node checks whether the members in the target group are addressable or not. Further, the action creates for all the members in the target group, a corresponding instance of campaign's OUTBOUND node. For example, for each target group member assigned to the campaign, the MRDO generates campaign outbound tracking record by calling a certain action of Business Object (BO) campaign and stores the tracking record in an outbound tracking table. During campaign execution, the outbound tracking table stores outbound contact information for every member (recipient) addressed in the execution of the campaign. For all members with a valid email address, the MDRO calls a service of the campaign management module 112 in order to generate a personalized HTML email. The generated personalized email is then sent out by the Output management module 118 via the mail server 130 to all the members.
In certain instances, the sent mails may need to be displayed on a UI for viewing at a later time. However, in the current mass campaigning scenario, storing a copy of every email that is sent out would consume large main memory space and hard disk space thereby increasing the processing runtime and decreasing performance. According to one or more embodiments, instead of storing each of the sent personalized entails completely, only that information that is needed to dynamically rebuild the sent email upon request is stored in the outbound tracking table. For example, for each recipient, the place holder values that are used to generate the corresponding personalized HTML email are stored in the outbound record for the recipient. In an aspect, the campaign's OUTBOUND node stores an Extensible markup language (XML) with the place holder values in a binary stream in a new element MAILBODY_PLACE_HOLDER=VALUE. This XML is provided by the Application program interface (API) of output management module 118 where the email body is personalized.
Further, information such as, the version (e.g., correspondence language) of mail template that was used in order to generate the personalized e-mail for the corresponding recipient (the contacted account contact person), is stored in the outbound record. In an aspect, the OUTBOUND node stores the UUID of the email template in a new element MAIL_FORM_UUID. A request to view a sent email may be provided by invoking a hyperlink on the field “Sent E-Mail” on the UI.
Upon receiving the request to view the email sent to a particular recipient, the campaign management module 112 executes an API class which invokes the outbound tracking table and reads the information relating to the e-mail template used and the place holder values for the particular recipient from the record. The action then retrieves the email template or a version of the email template assigned to the campaign from the node MAIL_FORM which stores the HTML email templates. The action then rebuilds/reconstructs the sent HTML: email by replacing the place holders in the mail body of the email template by the place holder values (attributes) pertaining to the particular recipient (account contact person) retrieved from the record. In an aspect, the place holder values are stored in campaign's OUTBOUND node in element MAIL_BODY_PLACE_HOLDER_VALUE. The reconstructed sent email may then be rendered on a graphical user interface of the client device 120.
Upon receiving the request, an outbound email tracking table having a tracking record for each recipient is invoked, at process step 220. The email tracking table holds a mapping of the plurality of recipients to specific versions of an email template. In an aspect, the mapping holds a link to the specific email template version. In order to recover the sent email for a particular recipient, that version of the template that was used for creating the original email is invoked. In an example, the same email template may be sent out to different recipients or groups of recipients in different languages. The information relating the particular version such as language code, template ID, description, or a link to the template is mapped to the recipient's name or email address in the tracking table. The email template outlines the content of the personalized email sent to the plurality of recipients and includes place holders for receiving variables specific to each recipient.
At process step 230, based on the mapping, the specific version of the email template that was applied in creating the email sent to the particular recipient is retrieved from a repository. The sent email is dynamically reconstructed at process step 240 using the email template and the corresponding place holder values from the outbound tracking table. In an aspect, the sent entail is rebuilt by replacing the place holders in the retrieved entail with variables specific to the particular recipient. In an embodiment, the mail body of the email template contains placeholders in a certain syntax, e.g.
At process step 250, the rebuilt sent email is then rendered on an output interface, e.g., a graphical user interface.
Referring to the example in
The e-mail template may be uploaded from a local file by selecting the “Add” option. Selecting the “Add” option opens a file selector pop-up of the client device's operating system. During the upload an API of the output management module 118 is called which checks the HTML syntax of the email template and converts the data stream into Extensible HyperText markup language (XHTML). The content of the uploaded HTML file will be stored as XHTML in the node MAIL_FORM of BO Campaign. In an aspect, the user manually enters the subject line for the uploaded email template and sets a language code of the uploaded email template. When the email template is uploaded, the description of the email template is displayed as hyperlink. Selecting this hyperlink opens a browser window and allows for preview of the email template.
Until the execution of the campaign the selected email template can be changed by just uploading a different template. In an aspect, in case the uploaded template contains errors (e.g. virus or invalid HTML code or wrong code page or wrong placeholder names) the template is rejected and corresponding error messages are rendered on the UI. The user may then upload another template or correct the erroneous template and upload it again.
For example, selecting the hyperlink description “E-mail opened” corresponding to recipient account Joerg stoneman, opens a UI as shown in
As shown in
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data Sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments, One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.