Artificial transactions in Opportunity Detect

When to use an ATX

Both types of ATX are useful when you want to detect a decline in customer activity. The End of Run ATX is most often used for production, and the End of Day ATX is most often used for testing.

Production

In most production use cases, batch files are processed every business day. Batch files for Tuesday, Wednesday, Thursday, and Friday contain transactions for the previous day. The batch file for Monday includes transactions from Friday, Saturday, and Sunday.

For the batch files that contain a transactions from a single day, The End of Run ATX produces the same results as the End of Day ATX. However, on Mondays, when transactions from three days are included, you want to process an account's transactions from all three days before firing a trigger indicating a decline in activity.

The trigger for a decline indicates that a customer did not do something, and it initiates a response urging the customer to resume the activity or asking why the decline occurred. If you respond in this way based on a Saturday transaction, and the customer contradicts that with a transaction on Sunday, you run the risk of sending an inappropriate response, because the customer's activity has not declined. This is when you would use an End of Run ATX to process all available transactions before responding to a decline in activity.

Testing

To simplify testing operations, you often put six months of transactions into a single file. You want to simulate the behavior of a production workspace running every business day with the ATX in End of Run mode. You can not use the End of Run mode, because the trigger indicating a decline would fire only once, after all six months of transactions have been processed.

Therefore, you would use the ATX in End of Day mode to approximate the behavior you would see in production. An End of Day ATX does not account for the Friday-Saturday-Sunday transactions all coming in on Monday, but with transactions from a long time period, it gives test results that are much closer to actual firing behaviors than the End of Run ATX.

Data dependency considerations for artificial transactions

When an event component uses an ATX as its incoming event, the descendent components that depend on it do not have access to any transaction data sources or to data components based on transaction data sources. The reason is that the system initiates the End of Day ATX after all the transactions have been processed.

The descendent components that depend on a component that uses an ATX do have access to a single profile data source. The first descendent component that uses a profile data source determines the profile data source available to all the other descendents of the component that uses the ATX. When you choose this profile data source in a descendent component, it should align with the profile data source used in the logic of the other transaction-based sections of your logic.

ATX in real time deployments

For real time, the ATX is always on and is set to End of Run.

In real time, a transaction set only has one transaction. The result is that the End of Run ATX is sent after every transaction even if there will be more transactions for that audience. When the ATX is sent, the components that are downstream from the component that uses the ATX perform their operations.

You can use an ATX with a real time deployment to activate consistent trigger logic after the transaction has been processed. Most often this is used to perform data calculations after the transaction has finished updating data. This can be useful in a production workspace, which typically contains many triggers. The ATX executes after all the triggers are processed. For example, Container components might be updated by the logic of several triggers before the ATX fires.

Artificial transaction example

The following ATX example illustrates a batch trigger system that a telephone company might use.

Suppose your goal is to take some action when a the average of a customer's call minutes used during a week is less than 70 percent of the average minutes per week used in the four weeks prior to that week.

To make the calculation required in this example, you must collect all call minutes for a complete week and compare their average with the average call minutes for the previous four weeks. The End of Day ATX ensures that all transactions for the week are included in the evaluation.

You can set up a trigger system as follows.

• Create a Simple component that fires an event when it receives customer call data.
• Create a Container component holds transactions that occur during a 90-day period.
  • In the Time Span panel, set a limit of 90 calendar days. Transactions with timestamps older than 90 days ago are cleared from the Container.

    Typically, you create Containers that can be useful in multiple trigger systems. This is why you specify that this Container stores more transactions than you need for this example.

• Create a Container Manipulator that listens for the Simple component event.
  • In the Action panel, specify that the call data is inserted into the Container.
• Create a Date component named Previous Week.
  • Use the Expression Builder to specify a date seven days in the past. The expression looks like this when complete: Now - Period(1,week).
• Create a Select component named Last Week to gather records from the past week.
  • In the Source panel, select the Container and select the timestamp and the field that holds the call minutes.
  • In the Where panel, create a WHERE clause that limits the data in the Select to records from the previous week.

    Specify records with timestamps greater than the date returned by the Previous Week Date component.

• Create a Date component named Five Weeks Ago.
  • Use the Expression Builder to specify a date five weeks in the past. The expression looks like this when complete: Now - Period(5,week).
• Create a Select component named Past Weeks to gather records from the time period between five weeks prior to the current week and the beginning of the current week.
  • In the Source panel, select the Container and select the timestamp and the field that holds the call minutes.
  • In the Where panel, specify the following two WHERE clauses to limit the data in the Select to records from the four weeks prior to the current week.
    • In one clause, specify records with timestamps less or equal to the date returned by the Previous Week Date component.
    • In another clause, specify records with timestamps greater than the date returned by the Five Weeks Ago Date component.
• Create an Action component that listens for an artificial transaction. In the Firing Condition panel, specify the following Boolean expression.
  • Compare the sum of the call minutes in the Current Week Select component to the sum of the call minutes in the Past Weeks Select component. The expression looks like this when complete, where the field that holds the call minutes is named call_minutes.

    [Last Week].[call_minutes].Sum() < [Past Weeks].[call_minutes].Sum()/4*0.7

When you run the example workspace, select an End of Day Artificial Transaction on the Batch Run tab of the workspace. The Artificial Transaction fires after the transactions for each day have been processed by the components upstream from the Action component.

When the Action component receives the ATX event, it performs its comparison for each customer, but it fires only when its firing condition criteria are met.

The following diagram illustrates this example.