Checking Automation Start / Kill dates.
This refers to checking that the start date in automation is before or equal
to the log date, and likewise that the kill date in automation is later then
the log date. Either one or both of these discrepancy types can be ignored
globally. This is the only setting for which there is no equivalent setting
for each event type.
Return To Top
Return To Top
-
Comparing
Description Fields Description
matching is a very interesting challenge. Consider that you have several
different people entering orders into the sales order system, copy
instructions into the traffic system, and cart descriptions into the
automation system. Maybe some stations have data entry standards, which
dictate exactly how each advertiser; spot title and ISCI code are to be
spelled and formatted when entered into all of these different systems, but
in practice this is highly unlikely. In order to deal with all of the
various ways descriptions may be entered, Media-Check uses what is referred
to as “fuzzy logic” when attempting to identify matches between descriptions
on the log and those in the automation system. Fine-tuning the percent
tolerance values, as well as utilization of the “Advanced Matching Options”
that Media-Check offers can have a dramatic effect on the accuracy of
description matching results (“Advanced Matching Options” will be discussed
in a later section). In some cases where these descriptions are being
entered in wildly different ways, it may be necessary to establish a policy
to enforce a somewhat standardized way things are entered into all of the
different systems. However, it is our intent at Power-Link to provide a wide
range of options that should allow the great majority of our clients ways to
setup tolerances and specify matching techniques such that Media-Check will
adapt to their way of doing business, rather than the other way around.
Another interesting situation that makes description matching even more
fascinating is that typically traffic logs have several description fields,
such as: Advertiser, Product, Spot Title, and ISCI, while most automation
systems have just a single, short field for the cart description. Some
automation systems do have a separate field for “Agency” (a.k.a. “ISCI”
codes) but we have found that in practice, this field is seldom used. The
way Media-Check addresses this gray area is to give you as many options as
we can, and then leave it up to you to experiment and see what works best in
your situation.
Be aware that the description matching issue cuts both ways like a
double-edged sword. If tolerances are too tight, many carts that are really
ok are going to show-up as discrepant—that’s a distraction, but the opposite
problem is much worse. If tolerances are set too wide, false positives
become a big problem. They are hard to catch, because carts that pass the
media-check don’t show up on reports. It completely defeats the purpose
using of Media-Check when a cart that was WRONG passes through unnoticed and
is aired in place of the correct one. A lot of work goes into this stage of
the process, but it is time well spent when you finally find the correct
combination of settings that works for your station.
Return To Top
User Adjustable Tolerances
-
Another thing that Media-Check does by default when matching
descriptions, is base the percentage match it finds on the length of
the shorter of the two fields being compared. This option allows you
to override the default behavior and to always base the percentage
match on the length of the inventory field, even if it’s longer than
the log fields.
Perhaps an explanation of part of Media-Check’s description matching
technique will make this more clear: When looking for a match
between the log and automation, Media-Check takes all of the
description fields from the log, excluding ISCI if we are looking
for it in the automation system’s dedicated ISCI field, and joins
them into one monolithic
field. We take all of the fields from the log because there’s no way
of telling which of these fields, or which parts of these fields,
will end up being a part of the description field entered into the
automation system. Next Media-Check removes all those bad
non-alphanumeric characters (except for your good ones) from both
the log and automation fields. Now one big nonsensical field from
the log is compared to the automation description field using our
aforementioned fuzzy logic methods. Sometimes a certain number of
sets of unique consecutive matching characters are found. In most
cases, the automation field is the shorter field and we use it as
the basis for computing the percentage match ([number of matching
characters found, divided by the length of the automation field] x
100 = percentage match).
But in a few extremely rare circumstances the log fields, even when
combined, are still shorter than the description field in
automation.
As an example: the log says “XBC” and the inventory description says
“XBC Sunday Night Movie.” Three is the maximum number of matching
characters that we could find, because the log just has 3 characters
in it’s description field: “XBC”, however the inventory description
is 20 chars long. This is the reason the default behavior is to use
the shortest field length. In this case the match would be 100%.
However if you use this option to force the inventory field length
to always be used, the match drops to 15%. If this is the way you
want to do it, this option is for you!
Return To Top
Return To Top
- Duration Warnings by
Comparing Cart Lengths
Comparing Cart
Lengths. This is one of the
items that does appear on the events tab, so there could be values
specified there that pertain only to certain event types which would
override any value entered here for events of that type.
There are two methods of evaluating the length of carts in the automation
system as compared to an event length from the log:
-
Method A.
This method, “% +/- Variance Log vs. Automation Length,” is the
easiest to specify. A percentage value is simply entered which applies
to all events regardless of their length. For instance, if the tolerance
is set at 10%, an event on the log that is 60 seconds long is allowed to
use carts that are within 54-66 seconds in length. At first glance, this
seems like a very good setting. Events that are 10 seconds long can
accept lengths of 9-11 seconds. That is starting to look like a very
strict rule. How more so for a 5-second spot? Only copy that is 4.5-5.5
seconds long will be acceptable. This would be a very difficult, if not
impossible, standard to meet for 5-second spots. But even with the
exaggerated effect percentage tolerances have on short events, this
method is the simplest to specify, and in many cases works just fine.
Please note that when a cart falls outside of these percentage tolerance
ranges, discrepancy reports will express the allowable tolerance in
terms of a range of allowable length values, consistent with the way
acceptable ranges of cart lengths are defined using Method B, below.
-
Method B.
“Specify Range for Each Cart Length” was designed to provide the
opportunity to have a much finer grained control of the range of cart
lengths in the automation system that are acceptable to use for an event
of a given length on the log. Using this method, you first enter an
event length that would appear on the log. Then enter the shortest
possible length of a cart in the automation system that would be
acceptable for this length event and likewise the longest length cart
that would be acceptable. Enter as many data points as you like.
However, traffic logs often contain a small set of standard event
lengths, so long lists of ranges may not be necessary. A very common set
of event lengths on a log might be :05, :10, :20, :30, and 1:00 These
are the default lengths used by the configuration editor, but it is
possible to use as many or as few as you like. The finer grained control
you need, the more data points that should be entered. The mechanics of
setting range values will be discussed shortly.
When the “Set Ranges” button on the Global tab page is pressed, this
window is displayed.
Return To Top
Return To Top
Comparing ISCI – Matching ISCI
codes is a whole different ballgame as compared to descriptions. ISCI codes
have very definite values; they are meant to be a unique combination
of letters and numbers that unequivocally identify a particular piece of
copy for a specific advertiser. However, given the aforementioned
notoriously short automation description field lengths, ISCIs often get
“abbreviated” or truncated when squeezed into an automation description
field along with product name, advertiser, etc.
So when doing ISCI matching, Media-Check assumes that if the whole ISCI is
not there, fully intact; that the portion of it that is there will be made
up of continuous characters from the original. It may have some characters
chopped off the front or back end, but it won’t be scrambled up with bits
and pieces all over the place. So ISCI matching is quite strict as compared
to the “fuzzy logic” methods used to match the other description fields.
There are ways of dealing with this, which will be discussed in the
following paragraphs.
Return To Top
Here you
can specify one range of carts to always ignore. The only rules in
specifying these ranges are that the range low and high must be matching in
kind. In other words C1-C999 is ok C1-G4, NOT ok. - C100-4300, NOT ok. Also
backward ranges, like L200-L1, NOT ok. You will not be allowed to save an
incorrectly formed cart number range.
- By entering any
number of single “cart number specifications” to this list you are
telling Media-Check to always ignore cart numbers matching the
specifications. The word “specification” is used because in addition to
simply entering explicit cart numbers to ignore like L1 or C22 you can
use “wildcard” characters in your specifications. By using wildcards in
a cart number specification, a single specification could potentially
match an unlimited number of different cart numbers. You are probably
already familiar with the two standard wildcard characters used by DOS
and Windows for specifying file names: “ * ” and “ ? ” (the splat, and
question mark).
Things like: “ N* ” would match any cart numbers starting with “N.” Or “
C3?? ” Would match any cart beginning with C 3 followed by exactly 2
more characters of any type.
That’s nice but not good enough for Power-Link. We have gone a few steps
further and taken pattern matching to a entirely new level with the
addition of the “ # ” and “ @ ” wildcard characters.
|
* |
Matches zero
to an unlimited number of any characters |
|
? |
|
|
# |
Matches
Exactly One numeric digit |
|
@ |
Matches
Exactly One alphabetical character |
Now you can specify wildcard matches that were not possible before.
For instance: “
X@1## ”
would match a cart number that was exactly 5 characters long, starting with
“X” followed by exactly on letter, followed by a “1” and then exactly two
digits. You can also use the old wildcards in combination with the new ones:
“ @5*A# “ would match a cart number of at least 4 characters in length
starting with any single letter then a “5” followed by zero or more of any
character except “A.” Then an “A” followed by any single digit. You
probably don’t use weird cart numbers like this, but if you do, Media-Check
can handle it.
This makes for some very specialized and accurate pattern matching, but
you’ve got to keep a few things in mind.
When you see
something like this “ *# ” in this case the splat can represent zero to an
infinite number of non-numeric characters because the first numeric
it encounters ends the splat’s run.
Likewise “ @*@ “
means that the splat can only contain non-alpha characters.
Interesting stuff,
but you’ve just got to be extra careful that you know exactly what
you’re asking for when using these new wild wildcards in your cart number
specifications.
Return To Top
Return To Top
-
General Email Recipient Options
1.
“Only Send Report if
Discrepancies Exist.” This
option is handy for those on your distribution list that don’t want to be
bothered unless there is s problem that needs attention. The only caution
with this option is that there should be SOMEONE on the recipient list who
is getting reports every day, even if there are no discrepancies. This
person will get used to receiving their report by a certain time every day
and if a report does not show up in their mailbox, can look into the matter
to assure that there is not a problem preventing Media-Check from sending
email. It may be that Traffic is just a little behind schedule finalizing
the log and the report will be a little late, but if there is a technical
glitch causing the problem, the appropriate people need to be made aware of
the situation so that it can be resolved. Otherwise the person using this
option may be lulled into thinking everything is ok, when there actually may
be some un-reported discrepancies.
2.
“Send Report as HTML.”
Checking this option tells Media-Check to send email in the much richer HTML
format. Leaving it unchecked will result in email reports being sent as
plain text. Note that this option is only meaningful if email is being sent
via the SMTP email method. Simple MAPI email does not support HTML content,
so if this is checked it will have no effect. Email will always be sent as
plain text for stations using MAPI. There will be more to follow regarding
the different email methods in the “Email Options” section.
3.
“Use for Daily Archive,”
“Use as Web/Show Me Report.” & “Use for Printed Report” These
checkboxes allow you to tell Media-Check which report format it should use
for archiving, web reporting, displaying an instant report with the SHOWME
feature of Run Media-Check, and printing. These checkboxes can be checked
for any report that is being sent to a particular email recipient, or may be
used with a report that is not being sent to anyone. If you want to use a
report that is not being emailed to someone for either of these purposes,
simply create a report format and check or more of these checkboxes. At that
point you can add the report to the list even though the email address and
name edit boxes are empty. Any of these options may only be assigned to one
report format. So if you have one report tagged for one of these options and
you subsequently set it for another report in the list, the report that
originally had the checkbox checked will have it removed.
If one of these checkboxes is not checked for any of the reports in the
list, a default report format will be used for that type of output.
Return To Top
Return To Top
-
Web Reports
1. This feature allows you to create a
web page containing a discrepancy report. You can choose any report format
you design, or use the default format. You can give the page a name, tell
Media-Check where to place the web page within your local or network file
system, change the background color, use a background image, and place a
banner image at the top of the page, aligned left, right or center.
This feature could be used to post a
discrepancy report on an INTERNAL web server, where interested people could
surf over to see what’s up with the log vs. the automation system.
You can choose to use the background
colors, background image and banner image specified here for HTML emails if
you like. The only consideration when using the images in emails is that
they need to be available at a URL on the Internet or your internal intranet
where an email client program can find them.
Return To Top
Return To Top
-
Get Up to Date Inventory
“Get Up to Date Inventory” will cause
the INVRead program to run and translate the automation inventory files for
the selected stations prior to calling Media-Check. This way Media-Check
will be using the freshest, most up-to-date inventory when checking against
the log.
This option has no effect when running INVRead by itself, since it always
gets the latest inventory.
Return To Top
Return To Top
-
Global Matching Criteria Tab
This tab
looks very much like the “Global Matching Criteria” tab; in fact it is
almost identical. The purpose of this tab is to allow all of the
configurability available on a global level to be broken out by event type.
So that, for instance: different tolerances could be used for PSAs or
Announcements than those that were set up globally for all other event
types. It also allows you to completely ignore all events of a certain event
type by checking the checkbox just above the little red circle in upper left
corner of screen, underlined in yellow.
You can also declare
that a particular event type is “Commercial” by checking the checkbox that
is circled in the top left-hand part of the screen. This event type
attribute is used in conjunction with the setting on the Global tab’s
“Advanced Settings,” which lets you tell Media-Check to “Only compare ISCI
on Commercial events.” It is also used when defining Preformatted Report
Styles-on the “Discrepancy Notifications” tab. You can create a report
template that applies only to these “Commercial” event types or the opposite
of that, only “Non-Commercial” event types.
Return To Top
Return To Top
Often ISCI code is embed somewhere inside
of the automation description field. Sometimes it’s at the beginning,
sometimes at the end. It could be anywhere. The point is, it is usually
there someplace and he wanted us to specifically try to identify the
embedded ISCI code wherever we could find it. But once we find an ISCI code
within the automation description field the story doesn’t stop there, we may
still be looking for other log description items like product name,
advertiser, or spot title in the field where we already rooted out the ISCI.
In this situation, there is no point looking for the other log fields inside
the portion of the automation field already identified as being the ISCI, so
we remove that portion of the automation description field which contained
the ISCI, recombine the remaining portions of the field, and now just search
what’s left for the other log description fields.
Return To Top
Return To Top
- The Executive Report
In order to allow a supervisor to keep tabs on continuity issues. this
selection produces a simplified report shown below:
