Three Real-world Considerations If you've read this far in our five-part series, congratulations! You've been introduced to each SAS Visual Scenario Designer 6.3 M1 window type, and have seen how each one analyzes raw or detail detail.    Before you choose a particular window type, it’s helpful to understand three primary, real-world considerations that influence your choice of window selection:   1. The rule that is being written Consider whether there are any time-based requirements for the aggregation. For the variables being used in the rules, you should decide whether to use all of the data, or to only use the most recent X days in your aggregate. In most cases, including a time element is very useful for keeping the analytics consistent. For example, if an aggregation window is used, the result is based on the entire table of data. This means that the result of the aggregation is dependent on the amount of data that is loaded to SAS LASR Analytic Server, rather than being defined as part of the window configuration. If you want to know the average ATM deposit amount for a customer, a better design approach might be to use a date-based aggregation window. Doing so makes the amount of data considered consistent regardless of the amount of history in SAS LASR Analytic Server.   2. The alert level Consider the level of output for the alert. For example, to generate an alert on an account, an aggregation window might be suitable. To generate an alert on individual transactions, a transaction window is needed.   3. The impact on the simulation Consider what you are trying to measure when you retrieve the results from SAS Visual Scenario Designer. If you are trying to answer what would generate an alert on a given date, then a date-based aggregation window works well. However, if you are trying to answer what would have generated alerts over the last X months, then a transaction window is probably required.   An Example The following example shows how you would obtain different results using the same raw data, based on the type of window that you use:   You create a building profile in order to determine when the entry time of an employee in a particular building differs by more than a minute from the average entry time. If you use an aggregation window, then you generate one average entry time that you associate with all the rows in your original data table:   Figure 1: Average Entry Time When Using an Aggregation Window   The average entry time of all five records in Figure 1 is 9:02:00. But if you run the records at the end of the day on January 1, then the average would actually be 9:00:30. Having one average and applying it to all of the records would lead to an inconsistency in the alerts being generated.   For example, the entry time of 9:00:00 for Employee ID 1 would not generate an alert if you ran the data on January 1, when the average entry time was 9:00:30. However, if you ran SAS Visual Scenario Designer on January 2, then you would find that the Employee ID 1 record triggers an alert because the average entry time is now 9:02. This results in an inconsistency between what you have in SAS Visual Scenario Designer and what you would obtain in a real production system with nightly batches.   Instead, if you used a transaction window, then you would generate an average for every single record in the data:   Figure 2: Average Entry Time When Using a Transaction Window   In this case, you would obtain an accurate average for every record. The run date of January 1 or January 2 has no impact on the result. Only past records influence the average, as shown by how the average entry time for each Employee ID adjusts to reflect the influence of earlier entry times for Employee IDs 1 through 3.   Understanding what you want to measure, the alert level that you want to generate, and the rule that you want to write enables you to determine which SAS Visual Scenario Window type to use.   What Next? When you have used a SAS Visual Scenario Designer window to explore, filter, and aggregate your data, you are ready to use this refined data set in a scenario that you create in SAS Visual Scenario Designer. You later deploy these scenarios to produce alerts or detect patterns of interest.   This is article #5 in a five-part series. See the links below for the previous articles: Part 1: Overview and Transformation Window Part 2: Aggregation Window Part 3: Date-based Aggregation Window Part 4: Transaction Window   ... View more

The Transaction Window The fourth type of SAS Visual Scenario Designer window is the transaction window. If you haven't yet read the previous articles that explain the behavior of the transformation window, aggregation window, and date-based aggregation window, it will be helpful to do so before proceeding. You'll learn concepts that will help you understand the information that follows.   Before we explain the particulars of how a transaction window behaves in SAS Visual Scenario Designer 6.3 M1, here again is the raw data and the detail data that are used in our examples:   Figure 1: Raw Data Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 7 5/3/2014 5PM 1 $2,000 8 5/3/2014 10PM 3 $3,000 9 5/4/2014 11AM 2 $4,000 10 5/4/2014 9PM 3 $2,000 11 5/5/2014 11AM 1 $3,000 12 5/6/2014 2PM 1 $3,000 13 5/7/2014 10PM 1 $2,500 14 5/8/2014 1PM 2 $1,000 15 5/10/2014 10AM 2 $2,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000 19 5/13/2014 4PM 1 $2,000   Remember that the detail data has the filter criteria of transactions at or above $3,500 applied to it, which results in the following output from our raw data:   Figure 2: Detail Data from a Transformation Window Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 9 5/4/2014 11AM 2 $4,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000     Figure 3 enables you to understand the elements in each animated slide that illustrate the behavior of a transaction window.   Figure 3: Legend     Similar to a date-based aggregation window, a transaction window also applies time-based lookbacks to aggregated data, but the transaction window differs in its output. Remember that a date-based aggregation window outputs one row per unique value for each group-by column, from the anchor end datetime through the lookback period.   In contrast, a transaction window outputs one row per incoming transaction. Transactions are aggregated using the group-by columns. Similar to the date-based aggregation window described previously, each variable has a lookback. With a transaction window however, the lookbacks are relative to the individual transactions themselves, and not to the anchor end datetime. Each transaction triggers a lookback period and aggregation from the timestamp of the current transaction.   As with a date-based aggregation window, you also set the number of time-based units, and you also define the value, or granularity, of the time unit. The difference is that a transaction window analyzes data to the millisecond level within that time unit. If you set DAYS as the time unit, then the date-based aggregation window does differentiate activity that occurred at different hours, minutes, seconds, and milliseconds within the day. For example, a one-day lookback from a timestamp value of 13 MAY 2014:02:12:47.123 aggregates data between 12 MAY 2014:02:12:47.124 and 13 MAY 2014:02:12:47.123. (123 and 124 represent millisecond values.)   A transaction window outputs an aggregation for each transaction in your raw data. However, transactions that don't meet your filter criteria are not included in the aggregation results. For example, the Member ID 1 transaction of $2,000 on 5/13/2014 4PM is not included in the results of the aggregations because it does not meet the filter criteria.   Note that in the following diagrams and tables, due to space considerations, the records for Member IDs 1, 3 and 4 are excluded, and the time units are at the HOURS level. The records for these Member IDs still meet the filter criteria, so the transaction window still analyzes and aggregates these records, down to the millisecond level, and still outputs those results.   Transactions at the HOURS Level Figure 4 depicts Member ID 2 transactions from the input table that meet the filter criteria. The transaction window is aggregating Deposit Amount and counting the number of Transaction IDs by Member ID. In this example, you see the window analysis of Member ID 2 transactions that meet the filter criteria, using the HOURS time unit. The window then applies a 72-unit time-frame lookback that applies to each Member ID 2 transaction. A 72-hour lookback, down to the millisecond level within that hour, is applied starting from the Member ID 2 transaction that occurs at 5/12/2014 8AM.   Notice that there are two distinct 72-unit time-frame lookbacks on 5/1/2014 – one for the 12PM transaction and one for the 8AM transaction. Also note that the lookback period that begins at 5/4/2014 11AM includes both the 5/2/2014 1PM transaction and the 5/1/2014 12PM transaction in its lookback period.   Figure 4: Aggregating by Member ID and Applying a 72-Unit Lookback to Each Transaction Where the Time Unit is HOURS   Figure 5 shows the aggregated data from this transaction window. The Transaction Count number displays how many transactions occurred within the lookback period. A transaction count of 3 exists for 5/4/2014 because Member ID 2 performed a single transaction at 5/4/2014 11AM (the end time in the lookback period), at 5/2/2014 1PM (59 hours – or time units – prior to the end time), and then at 5/1/2014 12PM (71 hours – or time units – prior to the end time). The bold font indicates how this transaction window that uses HOURS as its time unit can differ from the next example, which is a transaction window that uses DAYS as its time unit: when using HOURS, the inclusion of the 5/1/2014 12PM transaction in the lookback period for the 5/4/2014 11AM transaction results in one additional transaction and a Deposit Amount Sum that is $4,000 greater. Compare Figure 5 with Figure 9 to see this difference.   Note that records in your raw data that do not meet the filter criteria are aggregated by the transaction window, but are not included in the aggregation results. Member ID 2 transactions of $2,000 on 5/10/2014 10AM and $1,000 on 5/8/2014 1PM are such examples. A Deposit Amount Sum and Transaction Count value of 0 is returned for each.   Figure 5: Aggregating Deposit Amount and Counting Transactions by Member ID with Time-based Lookbacks Using a Time Unit of HOURS for Every Transaction Member ID Transaction ID Transaction Datetime Deposit Amount Sum Transaction Count 2 1 4/15/2014 8PM $5,000 1 2 2 5/1/2014 8AM $5,000 1 2 3 5/1/2014 12PM $9,000 2 2 5 5/2/2014 1PM $14,000 3 2 9 5/4/2014 11AM $13,000 3 2 14 5/8/2014 1PM $0 0 2 15 5/10/2014 10AM $0 0 2 16 5/10/2014 5PM $4,000 1 2 18 5/12/2014 8AM $9,000 2     Transactions at the DAYS Level What if you analyze Member ID transactions over three days, using the same filter, but this time using a 3-unit time-frame lookback where the unit is DAYS, and not HOURS? Because a transaction window analyzes data down to the millisecond and creates lookbacks for any transactions that occur within smaller, more granular time units, the results are identical.   But what if you want a transaction window to differentiate between and create lookbacks for member transactions only down to the level of the time unit (DAYS, HOURS, MINUTES or SECONDS) that you assigned, with no differentiation between lookbacks for transactions that occur at smaller, more granular timestamp variables? Assigning an equal value to those smaller timestamp variables accomplishes this. For example, if you selected a time unit of HOURS, then you would assign a value of 59 to MINUTES and SECONDS, and a value of 999 to milliseconds. The transaction window still analyzes detail data to the millisecond level, but it does not differentiate between transactions that occurred at MINUTES, SECONDS, or MILLISECONDS within the hour because you have assigned identical values to these time stamps.   Figure 6 shows 999 for the MILLISECOND value, 59 for the incrementally larger timestamp values (SECONDS and MINUTES) and 23 for HOURS, within the data set. It is preferable to use 999, 59, and 23 for the other timestamp values, not 000 or 00. This is because a transaction window is looking backward from the end date value, and not forwards from the start date value. XX in the table below represents the current timestamp value that you have selected as your time unit, which could be any valid value.   Making these adjustments means that the transaction window differentiates only between activity that occurs at the time unit that you define.   Figure 6: Time Unit Values Time Unit Value DAYS 23:59:59.999 HOURS XX:59:59.999 MINUTES XX:XX:59.999 SECONDS XX:XX:XX.999   With DAYS as the time unit, and with 23 for HOURS, 59 for MINUTES and SECONDS and 999 for MILLISECONDS, the transaction window effectively only uses the DAYS portion of the datetime value in its lookback period. In this window that outputs one row per transaction per unique value for each group-by column, the lookback periods in Figure 7 do not distinguish between the different hours that each transaction occurred.   Note: SAS LASR Analytic Server processes transactions within the same time unit in arbitrary order, which is not guaranteed to be consistent from run to run. For example, Transaction ID 2 and Transaction ID 3 (both of which occur on 5/1/2014) could be processed by SAS LASR Analytic Server either as 2 followed by 3, or as 3 followed by 2.   In Figure 7, notice that the lookback period for the 5/4/2014 transaction looks back to 5/2/2014, and therefore does not include the 5/1/2014 transaction that was included when HOURS was the time unit (as shown in Figure 4).     Figure 7: Aggregating by Member ID and Applying a 3-Unit Lookback to Each Transaction Where the Time Unit is DAYS   The table in Figure 9 shows the aggregated data from this window. The bold font for 5/4/2014 indicates how – when smaller, more granular time stamps are assigned identical values – this window that uses DAYS as its time unit differs from the previous window example that uses HOURS as its time unit: the omission of the 5/1/2014 12PM transaction results in a Transaction Count of 2 and a Deposit Amount Sum of $9,000. Compare these results with the results shown in the table in Figure 5.    Transactions in your raw data that do not meet the filter criteria do not participate in the aggregation results. In this example, Member ID 2 Transaction IDs 14 and 15 are such examples: $2,000 on 5/10/2014 10AM and $1,000 on 5/8/2014 1PM.   Recall that SAS LASR Analytic Server processes transactions that occur within the same time unit in arbitrary order., Because this transaction window effectively only uses the DAYS portion of the datetime value in its lookback period, the Deposit Amount Sum and Transaction Count for both 5/10/2014 Member ID 2 transactions can equal $4,000 and 1, respectively, depending on the order that SAS LASR Analytic Server processes them.   Here again are the 5/10/2014 transactions for Member ID 2, as they appear in the raw data in Figure 1:   Figure 8: 5/10/2014 Transactions for Member ID 2 Member ID Transaction ID Transaction Datetime Deposit Amount 2 15 5/10/2014 10AM $2,000 2 16 5/10/2014 5PM $4,000     Of these two 5/10/2014 transactions, only the $4,000 transaction at 5PM meets the filter criteria, so that is the only 5/10/2014 Member ID 2 transaction that participates in the aggregation results. Hence the Deposit Amount Sum of $4,000 and the Transaction Count of 1. The table below shows the resulting Deposit Amount Sum and Transaction Count if SAS LASR Analytic Server processes the 5/10/2014 $4,000 transaction (Transaction ID 16) first.   Figure 9: Aggregating Deposit Amount and Counting Transactions by Member ID with Time-based Lookbacks Using a Time Unit of DAYS for Every Transaction Member ID Transaction ID Transaction Datetime Deposit Amount Sum Transaction Count 2 1 4/15/2014 $5,000 1 2 2 5/1/2014 $5,000 1 2 3 5/1/2014 $9,000 2 2 5 5/2/2014 $14,000 3 2 9 5/4/2014 $9,000 2 2 14 5/8/2014 $0 0 2 15 5/10/2014 $4,000 1 2 16 5/10/2014 $4,000 1 2 18 5/12/2014 $9,000 2   If SAS LASR Analytic Server processes the 5/10/2014 $2,000 transaction (Transaction ID 15) first, then the rows for Transaction IDs 15 and 16 would appear as follows:   Figure 10: 5/10/2014 Transactions for Member ID 2 If Processed in a Different Order Member ID Transaction ID Transaction Datetime Deposit Amount Sum Transaction Count 2 16 5/10/2014 $4,000 1 2 15 5/10/2014 $0 0   Conclusion You might use a transaction window to see the three-day sum of deposits per member for each transaction that occurs within the filter criteria.   This is article #4 in a five-part series. See the links below for the additional articles: Part 1: Overview and Transformation Window Part 2: Aggregation Window Part 3: Date-based Aggregation Window Part 5: Knowing Which Window Type to Choose   ... View more

The Date-based Aggregation Window The aggregation window type described in the previous article can also apply time-based lookbacks to your data. Make sure to check out the previous articles in this SAS Visual Scenario Designer 6.3 M1 Windows article series to better understand the information that follows.    Before we explain the particulars of how a date-based aggregation window behaves in SAS Visual Scenario Designer 6.3 M1, here again is the raw data and the detail data that are used in the examples in this article:   Figure 1: Raw Data Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 7 5/3/2014 5PM 1 $2,000 8 5/3/2014 10PM 3 $3,000 9 5/4/2014 11AM 2 $4,000 10 5/4/2014 9PM 3 $2,000 11 5/5/2014 11AM 1 $3,000 12 5/6/2014 2PM 1 $3,000 13 5/7/2014 10PM 1 $2,500 14 5/8/2014 1PM 2 $1,000 15 5/10/2014 10AM 2 $2,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000 19 5/13/2014 4PM 1 $2,000   Remember that our detail data applies a filter criteria of transactions at or above $3,500:   Figure 2: Detail Data from a Transformation Window Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 9 5/4/2014 11AM 2 $4,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000   And here again is the legend, which helps you to understand the animated images that display different types of date-based aggregation window behavior:   Figure 3: Legend   A date-based aggregation window analyzes your data from the anchor end datetime back through an adjustable number of time-based units, such as DAYS or HOURS. Total activity (in this example, Deposit Amount) for each unique value of a group-by column or columns that occur within the lookback period (that is, a time-based filter used for analyzing data) is the focus here.   The end time is assigned a default value of the latest date or datetime in the input data set. The default lookback period is 1 and each additional time unit that you assign has a value of 1. For example, a 3-unit time-frame lookback period that uses DAYS as its time unit looks back over a total of 3 days: the end time, or final day (1), and two days preceding that (2). Similarly, a 72-unit time-frame lookback period that uses HOURS as its time unit looks back over a total of 72 hours: the end time, or final hour (1); and seventy one hours preceding that (71). Each of these methods covers the same span of time, but each may return different results, as you will see in the following diagrams.   You set the number of time-based units (1, 2, 3, and so on), and you define the value, or granularity, of the time unit (DAYS, HOURS, MINUTES, and SECONDS). The date-based aggregation window only returns results at that level of granularity within that time unit. If you set HOURS as the time unit, then SAS Visual Scenario Designer does not differentiate activity that occurred at smaller time units (MINUTES, SECONDS) within the hour.   A date-based aggregation window outputs one row per unique value for each group-by column from the anchor end datetime through the lookback period. Note that if there are no rows for a given group-by column that meet the lookback criteria, then these group-by values are not included in the output.   Date-based Aggregation at the HOURS Level Figure 4 depicts the behavior of a date-based aggregation window. It depicts Member ID transactions that meet the filter criteria of being at or above $3,500. The window is aggregating the Deposit Amount by Member ID. The window applies a 72-unit time-frame lookback period, where the time unit is HOURS, from the end date of 5/13/2014 4PM. Therefore, the window analyzes Member ID ATM transactions at the hour level from 5/13/2014 4PM through 5/10/2014 4PM.   Figure 4: Aggregating by Member ID and Applying a 72-Unit Lookback where the Time Unit is HOURS Figure 5 shows the aggregated data from this window. Between 5/13/2014 4PM and 5/10/2014 4PM, the following transactions occurred (refer back to the table in Figure 1 if you need a reminder):   Member ID 1 performed one transaction of $2,000 on 5/13/2014 4PM, which is below the filter criteria and therefore is not included in the aggregation results. Member ID 2 performed one transaction of $5,000 on 5/12/2014 8AM and one transaction of $4,000 on 5/10/2014 5PM. Member ID 4 performed one transaction of $12,000 on 5/10/2014 8PM.   The Deposit Amount Sum column returns the sum of the deposit amount for transactions that meet the filter criteria of deposit amount being at or above $3,500 for each Member ID. For Member ID 2, that means that the 5/13/2014 Deposit Amount Sum is the sum of the 2 transactions that occur within the lookback period: $5,000 on 5/12/2014 8AM, and $4,000 on 5/10/2014 5PM, for a deposit amount sum of $9,000. Because the Member ID 1 transaction of $2,000 does not meet the filter criteria, Member ID 1 has a Deposit Amount Sum of 0.   In a date-based aggregation window, every transaction within a lookback period gets the same anchor end datetime. In this example, that is 5/13/2014 4PM.    Figure 5: Aggregating Deposit Amount by Member ID Using a Lookback Time Unit of HOURS Anchor Datetime Member ID Deposit Amount Sum 5/13/2014 4PM 1 $0 5/13/2014 4PM 2 $9,000 5/13/2014 4PM 4 $12,000   Date-based Aggregation at the DAYS Level What happens if you analyze Member ID transactions over three days, using the same filter, but using a 3 unit time-frame lookback where the time unit is DAYS?   With DAYS as its time unit, the date-based aggregation window now only uses the day portion of the datetime value in its lookback period. Therefore, this window analyzes Member ID ATM transactions from 5/13/2014 (the end date, or 1) back through 5/11/2014 (the two days – or time units – preceding that). The 5/10/2014 transactions from Member ID 4 and Member ID 2 are now excluded. The diagram in Figure 6 depicts this difference in lookback behavior.   Figure 6: Aggregating by Member ID and Applying a 3-Unit Lookback where the Time Unit is DAYS Figure 7 shows the aggregated data from this window. Between 5/13/2014 and 5/11/2014, the following transactions occurred:   Member ID 1 performed one transaction of $2,000 on 5/13/2014, which is below the filter criteria of $3,500, and therefore is not included in the aggregation results. Member ID 2 performed one transaction of $5,000 on 5/12/2014.   Notice that both of the Member ID 2 and Member ID 4 transactions on 5/10/2014 are excluded.   Figure 7: Aggregating Deposit Amount by Member ID Using a Lookback Time Unit of DAYS Anchor Datetime Member ID Deposit Amount Sum 5/13/2014 1 $0 5/13/2014 2 $5,000   Conclusion No matter what time unit you select, you might use a date-based aggregation window to see a summary of the total cash deposits for each bank member from the anchor date through a lookback period of three days.   This is article #3 in a five-part series. See the links below for the additional articles in this series: Part 1: Overview and Transformation Window Part 2: Aggregation Window Part 4: Transaction Window Part 5: Knowing Which Window Type to Choose ... View more

The Aggregation Window In the previous article, you were introduced to each type of window in SAS Visual Scenario Designer 6.3 M1, and you learned how the transformation window analyzes raw data to create detail data. This article introduces you to the aggregation window, and explains how it analyzes your raw data or detail data.   Here's a recap of the raw data that we're using for the examples in these articles:   Figure 1: Raw Data Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 7 5/3/2014 5PM 1 $2,000 8 5/3/2014 10PM 3 $3,000 9 5/4/2014 11AM 2 $4,000 10 5/4/2014 9PM 3 $2,000 11 5/5/2014 11AM 1 $3,000 12 5/6/2014 2PM 1 $3,000 13 5/7/2014 10PM 1 $2,500 14 5/8/2014 1PM 2 $1,000 15 5/10/2014 10AM 2 $2,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000 19 5/13/2014 4PM 1 $2,000   Here again is the detail data that the transformation window outputs:   Figure 2: Detail Data from a Transformation Window Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 9 5/4/2014 11AM 2 $4,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000   How then does an aggregation window in SAS Visual Scenario Designer 6.3 M1 work? It summarizes raw or detail data across distinct category values, such as member ID, age or transaction type. The resulting data set includes one row for each unique combination of the category values.   An aggregation window uses group-by columns to aggregate, or segment, data into groups based upon the unique value in each group-by column. For example, selecting age and gender creates a grouping of age, and within age, a grouping of gender. Group-by columns are synonymous with partition keys, and are the level to which the data is aggregated. When you select one or more group-by columns, the resulting data set includes one row for each unique group-by column value. For example, if you applied a group-by column of day of the week, then you would have a data set of seven rows – one for each day of the week. The values that are associated with the group-by column or columns are automatically included in the resulting data set.   The legend below enables you to understand the elements in the animated image that follows.   Figure 3: Legend     In the following image, a group-by column of Member ID has been applied to the detail data (as shown in Figure 2). As a result, Member ID is the group-by column that aggregates the data by Deposit Amount Sum and by Transaction Count.   Figure 4: Aggregating by Member ID Figure 5 shows the aggregated Deposit Amount Sum and Transaction Count results from an aggregation window.   Figure 5: Aggregating Deposit Amount and Counting Transactions by Member ID Member ID Deposit Amount Sum Transaction Count 1 $4,000 1 2 $32,000 7 3 $8,000 1 4 $12,000 1   You might use an aggregation window to find total cash deposits per member that occur within the filter criteria.   This is article #2 in a five-part series. See the links below for the additional articles: Part 1: Overview and Transformation Window Part 3: Date-based Aggregation Window Part 4: Transaction Window Part 5: Knowing Which Window Type to Choose ... View more

Overview If you read the recent What is SAS Visual Scenario Designer? article, then you have a general understanding of the benefits and functionality of SAS Visual Scenario Designer. Because creating a window is one of the first actions that you'll do, it helps to understand how each window type in the upcoming release of SAS Visual Scenario Designer 6.3 M1 analyzes the raw data from the SAS LASR Analytics Server. This article, part one in a five-part series, introduces you to the four window types, and explains how the transformation window works.     A window in SAS Visual Scenario Designer takes raw input data and applies filter conditions to it, to create what's known as detail data. Depending on the options that the user selects, a SAS Visual Scenario Designer window then aggregates this detail data.   Knowing how each window analyzes your raw or detail data enables you to understand why you might choose a particular type.    The Four Window Types In SAS Visual Scenario Designer 6.3 M1, a window can analyze your data in four different ways:   A transformation window applies any specified filter conditions to your raw data and outputs detail data. This window type does not aggregate data. It can be useful for writing a scenario directly against an input table or for reducing data volumes within the system by dropping columns or rows. An aggregation window aggregates raw or detail data by one or more group-by columns, and outputs one row per unique group-by value for all of the records in the window. It can be useful for calculating statistics (such as averages) across the entire table. A date-based aggregation window aggregates raw or detail data by one or more group-by columns, and outputs one row per unique group-by value. The difference between a non-date based aggregation window and a date-based aggregation window is that the latter assigns a lookback to each group-by column. This lookback only considers the data within the most recently specified lookback period, looking backward from the end date value. A transaction window aggregates raw or detail data by one or more group-by columns, and outputs one row per transaction. Similar to the date-based aggregation window, each transaction has a lookback. The difference is that each lookback only considers the data from the date of the individual transaction.  Each of these approaches can yield different results, so it's important to understand how each one differs, so that you can choose the one that best suits your needs.   The Raw Data Each Window Will Analyze Before we discuss the first type, the transformation window, here's the hypothetical raw data that we'll be using in the examples presented throughout these articles:   Our hypothetical raw data is the following ATM transactions that occur between 4/15/2014 8PM and 5/13/2014 4PM. (Due to space considerations in the animated diagrams that appear in later articles, minutes or seconds values for the transaction datetimes are not provided.)   Figure 1: Raw Data Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 7 5/3/2014 5PM 1 $2,000 8 5/3/2014 10PM 3 $3,000 9 5/4/2014 11AM 2 $4,000 10 5/4/2014 9PM 3 $2,000 11 5/5/2014 11AM 1 $3,000 12 5/6/2014 2PM 1 $3,000 13 5/7/2014 10PM 1 $2,500 14 5/8/2014 1PM 2 $1,000 15 5/10/2014 10AM 2 $2,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000 19 5/13/2014 4PM 1 $2,000   The Transformation Window A transformation window analyzes your raw data according to filter criteria that you define. This detail data has not been aggregated (for more information, see the Aggregation Window article), and is at the same level as the raw data. The resulting output contains those values in the raw data that meet the filter criteria. A transformation window produces one output record per input record that meets the filter criteria. In this example, your filter criteria filters out any transactions that are lower than $3,500 so that you are left with only high-value transactions in your window:   Figure 2: Detail Data from a Transformation Window Transaction ID Transaction Datetime Member ID Deposit Amount 1 4/15/2014 8PM 2 $5,000 2 5/1/2014 8AM 2 $5,000 3 5/1/2014 12PM 2 $4,000 4 5/1/2014 11PM 3 $8,000 5 5/2/2014 1PM 2 $5,000 6 5/3/2014 9AM 1 $4,000 9 5/4/2014 11AM 2 $4,000 16 5/10/2014 5PM 2 $4,000 17 5/10/2014 8PM 4 $12,000 18 5/12/2014 8AM 2 $5,000   Why use a transformation window? You might do so to obtain a subset of data from a larger data set, such as retaining only records that are ATM deposits (rather than withdrawals). Doing so speeds up the processing time for any dependent windows because the data being passed to them is reduced.   The transformation window has two other typical use cases:   Dropping or renaming columns from the input table. Again, this can be used to reduce the data that is sent to downstream windows by only keeping what is required for the scenarios. Creating calculated columns that do not require aggregation, and that instead operate on individual rows within the input data. An example of this is producing a new field that is the maximum of 0 and the deposit amount to remove negative values. This is article #1 in a five-part series. See the links below for the additional articles:    Part 2: Aggregation Window Part 3: Date-based Aggregation Window Part 4: Transaction Window Part 5: Knowing Which Window Type to Choose ... View more

Hey folks. My name is Ben and I wrote the documentation for SAS Visual Scenario Designer 6.3. If you’re interested in learning more about SAS Visual Scenario Designer, check out the recent What is SAS Visual Scenario Designer? article and keep an eye out for future posts in the SAS Visual Analytics community page. If you have any questions about SAS Visual Scenario Designer, post them in this forum and I’ll do my best to answer them. I look forward to future discussions with you! Sincerely, Ben ... View more

What is SAS Visual Scenario Designer?   SAS Visual Scenario Designer is the first data-driven solution for interactive rule and scenario authoring, testing, and validation. Supporting both batch and real-time streaming deployment options, it is integrated with the SAS Visual Analytics suite. This integration enables you to explore, test, and develop analytic models and scenarios as part of the scenario and rule authoring process. With a license, you can access SAS Visual Scenario Designer from the SAS Visual Analytics Hub.   Accessing SAS Visual Scenario Designer from the SAS Visual Analytics Hub   SAS Visual Scenario Designer: Main Screen Several other features make SAS Visual Scenario Designer unique: Full back testing, governance, and “what if” scenario analysis capabilities Easy-to-use advanced analytics enable you to uncover previously unknown patterns in your data Integration with SAS Event Stream Processing Engine for deploying real-time low latency scenarios Integration with SAS Laser Analytic Server for performing batch and interactive decision making     How will SAS Visual Scenario Designer help me?   The responsive design of SAS Visual Scenario Designer enables you to prepare, transform, explore and uncover patterns of interest in your data. Unlike traditional rule-based systems, which are not data-driven, SAS Visual Scenario Designer enables you to shape your rules with data – lots of data. The integration with SAS Visual Analytics means that you can explore data as you develop scenarios and rules, which gives you a clear understanding of the interrelationships within your data. Integration with statistical components like SAS Visual Statistics enables you to develop exploratory models using logistic regression, decision trees, and clustering algorithms as part of your decision making or scenario process. SAS Visual Scenario Designer also provides simulation capabilities so that you can back-test scenarios and rules over time, as well as perform “what-if” analyses to see the impact of rule changes before deployment.     How does SAS Visual Scenario Designer work?   SAS Visual Scenario Designer consists of four main components: windows, scenarios, deployments, and simulations.   1. A window is how SAS Visual Scenario Designer takes raw-input data and aggregates or prepares it for analysis. Most data of interest comes in the form of transactions or events, and generally has a time element to it. A window is simply a summary of this input data. Windows enable you to author variables using time- and order-based conditional control.  Aggregation and date-based lookbacks are two common examples.       SAS Visual Scenario Designer: Window Screen     2. A scenario is the combination of business rules applied to a window. SAS Visual Scenario Designer provides a number of rule or scenario authoring tools to aid in the decision making and rule authoring process. These include decision tables, decision trees, and a cross-tab rule explorer. Rule actions enable you to apply business decisions to data. For example, in the case of fraud, an action might be to generate an alert, while in the case of a loan decision it might be to approve or decline a loan application.       SAS Visual Scenario Designer: Scenario Screen     3. A deployment enables you to deploy scenarios for operational consumption. SAS Visual Scenario Designer currently supports two execution engines: the SAS LASR Analytic Server and the SAS Event Stream Processing Engine. You can apply parameter values that you can customize for your organization.       SAS Visual Scenario Designer: Deployment Screen     4. A simulation enables you to test and apply “what-if” analyses to simulating different business conditions or assessing the impact of decision changes. You can test impacts such as rule thresholds or compare the results of an execution over time.       SAS Visual Scenario Designer: Simulation Screen     Here are some tasks that you can perform when working with the four main components: Create a window where you select, prepare, and explore data for use in a scenario. Author scenarios based on business rules, data exploration, and statistical models. Deploy your scenarios to produce alerts or detect patterns or events of interest. You can customize the activation to fit any subset of your entire organization and specific time periods. Simulate the impact of scenarios on operations by comparing different time periods, different data, or changes in rules over time.     What next?   You can use the events or patterns of interest that you identify in SAS Visual Scenario Designer in other applications (such as SAS Visual Analytics or SAS Visual Statistics) to generate potential alerts. ... View more