Adding a measure as a filter means you only want to include Purepaths, user actions, or visits (depending on your BT type) in the "bucket" of data you are collecting. Calculate results measures are the measures you would like to see included in the "results" of your BT. So for instance if you were interested in the execution time of a certain web service call for /home web requests, you can include a measure that filters on /home requests and add a calculate results measure for the web service call time and it will aggregate the service call time across all requests that meet your filter.
If you're at all familiar with SQL calls you can think of the filter as the "where" and the calculate as the "select". The Splitting measures likewise can be thought of as the "group by" in such a query.
Does that help?
While our Dynatrace documentation has more in depth information on this particular subject (business transactions) i can give you a some input to this question.
So a business transaction is basically a collection of purepaths that meet a certain criteria and also display certain criteria. So the Results table allows you to pick what exact measure you want to have in your business transaction, so lets say you'd like to see the DB time metric as a result of your Business transaction. that means the results (purepaths) that match this Business transaction will also have that added DB time metric (along with response time).
The Filter is just as the name implies a mechanism to eliminate a bunch of purepaths that do not fit what your looking for. So a filter for example could be the invocation of certain method. Using our previous example, we would then eliminate all purepaths (with db time as result) that do not meet our filter which is the invocation of that method.
The third result, which you may be familiar with is the split, which is taking the purepaths that have your result and match your filter and simply organizing them by some relevent metric, such as user name, browser etc.
In short the results are the specific measurements you wish to know from the purepaths, the Filter is what eliminates the purepaths you dont want, and the split is the logical way to organize your output from your business transaction. Hope this helps.
For sake of rudimentary example, let's say Dynatrace AppMon is capturing red, blue, and yellow transactions and you want to know a few things about the red transactions. What you do is make a Business Transaction and set it's filter to only capture red transactions. Now that you're only considering the red transactions you need to define those few things you wanted to know about those red transactions; this is done by using the Calculate Results section.
In terms of Splitting this may or may not be of interest to you depending on your use case but it is able to separate your red transactions into categories based on the split measure you choose. So for example the default split is applications. So it (in this rudimentary example) separates all your red transactions into separate buckets where each bucket represents a separate application.