Tracing source of web app call | Community
Skip to main content
SonnyRD
SonnyRD
Level 2
September 5, 2019
Solved

Tracing source of web app call

  • September 5, 2019
  • 4 replies
  • 4332 views

Hello--

Just wondering if anyone here has ideas on how to trace a web app call to determine source. I have a web app that takes in name, email address and service ID to add that new recipient to a service (an email newsletter subscription, in this case). We have removed the one web page that we know that's been using this web app (essentially a web form that's using an HTTP POST command), but for some reason, I keep seeing new signups every day. Our marketing team is not aware of any active acquisition channel for this newsletter at this time, so this is very bizarre.

Is there any way to figure out where these new signups are coming from?

Thanks in advance for any insights. I have a ticket open with Customer Care, but just wondering if anyone here had come across this situation before.

Sonny

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Jean-Serge_Biro

    Hi Sonny,

    Yes, the Google Analytics/Adobe Analytics idea is bad, it was if the location to find comes from  the website(s) that your company manages by their own.

    For the past webApp calls:

    Httpd access log files is the king for getting full view. But huge files...
    Many tools are dedicated to analyse log files, and some for httpd access files.
    But being on Cloud hosted, you won't be able to use them.

    I don't know if Adobe support team will accept to send you an extract of httpd log files, filtered on your webApp and sub-domain name prefix of the url, so you could analyze like this sample record (for IIS httpd server).
    Here true record, replaced by sample value:
    Ask for filtering on https://yoursubdomainhostedbyadobeoncloud/webApp/yourwebappinternalname

    2019-09-05 00:01:21 <AdobeCampaignIPaddressserver> GET /nl/gen/min/WA-fr-8af691832ebdf28de8c5eb70fa258844.js - 443 - theclientIPaddresstocheck Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_14_5)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/12.1.1+Safari/605.1.15 https://yoursubdomainhostedbyadobeoncloud/webApp/yourwebappinternalname?origin=yourspecificvalue 200 0 0 0.

    For the coming calls:

    Please modify your webApp, add some Javascript code to collect information about http referrer and other useful information (http headers, etc, store these values into web.log files (with logInfo()) or better in database tables (such as webapplog schema extended custom field) and republish it, so for coming calls, you will be able to have detailed information and better understanding.

    Regards
    J-Serge

    4 replies

    Jean-Serge_Biro
    Jean-Serge_Biro
    Level 10
    September 6, 2019

    Hi SonnyRD,

    Do you have already a web tracking system such as Google Analytics, Adobe Analytics, Xiti implemented in your web page?
    In that case, you can study from where your visitors come to your Adobe Campaign webApp.

    If not, it is not useful to activate the out-of-the-box web tracking in your webApp, in Properties General tab (field @webTrackingEnabled)

    (https://docs.campaign.adobe.com/doc/AC/en/WEB_Web_applications_Tracking_a_web_application.html)

    because unfortunately the nms:webTrackingLog table doesn't contain @IP address.

    So what you can do, if you are On Premise, is to analyse the httpd access log files to see the IP addresses, so you will get the IP addresses and then you can know the domain names/geographical etc and perhaps understand a bit if it comes from a web site.

    If there are private IP addresses (ISP providers) it means probably that the users put the webApp in favorite/shortcuts and accede them directly. Or perhaps do you have a emailing campaign that provided to them the webApp link directly ?

    For next webApp, please think to add an ?origin=XXX parameter to your emailing campaign pointing to a webApp, and the same for websites leading to your webApp, it helps a lot to analyse origin (in addition of tools as Google Analytics/Adobe Analytics).

    Regards
    J-Serge

      SonnyRD
      SonnyRDAuthor
      Level 2
      September 6, 2019

      Hello Jean-Serge--

      Thank you for your reply. You're right; web tracking in the web app properties will not help in this case. Yes, we have GA but the problem is that I don't know which web page is using the web app. We have shut down this newsletter service and basically deleted the web page where we used to collect subscribers (and we have stopped sending emails to them since early August), which is why it's puzzling that we're still getting new signups. I am assuming that this source is some rogue legacy page (or worse, some sort of a script) that has predated all of us on the team and so no one knows about it (which is terrible, I know, but oh well). As an aside, every single one of these new subscribers has a hard-coded zip code of 55401 (Minneapolis, MN -- where we don't have a market presence; the newsletter was local to Oregon residents!)

      And yes, every web app that I created after I started on this job has that origin parameter in the query string for attribution, reporting and analysis purposes.

      Which leaves us with the logging. I like this idea. We are not on-prem, but I suppose I can ask Adobe Support to enable verbose logging for at least a day?

      Thanks again,

      Sonny

      Jean-Serge_Biro
      Jean-Serge_BiroAccepted solution
      Level 10
      September 6, 2019

      Hi Sonny,

      Yes, the Google Analytics/Adobe Analytics idea is bad, it was if the location to find comes from  the website(s) that your company manages by their own.

      For the past webApp calls:

      Httpd access log files is the king for getting full view. But huge files...
      Many tools are dedicated to analyse log files, and some for httpd access files.
      But being on Cloud hosted, you won't be able to use them.

      I don't know if Adobe support team will accept to send you an extract of httpd log files, filtered on your webApp and sub-domain name prefix of the url, so you could analyze like this sample record (for IIS httpd server).
      Here true record, replaced by sample value:
      Ask for filtering on https://yoursubdomainhostedbyadobeoncloud/webApp/yourwebappinternalname

      2019-09-05 00:01:21 <AdobeCampaignIPaddressserver> GET /nl/gen/min/WA-fr-8af691832ebdf28de8c5eb70fa258844.js - 443 - theclientIPaddresstocheck Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_14_5)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/12.1.1+Safari/605.1.15 https://yoursubdomainhostedbyadobeoncloud/webApp/yourwebappinternalname?origin=yourspecificvalue 200 0 0 0.

      For the coming calls:

      Please modify your webApp, add some Javascript code to collect information about http referrer and other useful information (http headers, etc, store these values into web.log files (with logInfo()) or better in database tables (such as webapplog schema extended custom field) and republish it, so for coming calls, you will be able to have detailed information and better understanding.

      Regards
      J-Serge

        SonnyRD
        SonnyRDAuthor
        Level 2
        September 6, 2019

        The log file approach seems promising. Worth asking Adobe Support, even if to enable logging for only a couple of hours (I can probably check to see if there's a pattern with previous signups to get the "most popular" time of the day that they're coming in).

        Great idea with the JS code! Maybe something like document.referrer could work. Let me try this on a test web app and see what turns up. Thanks so much!

        Sonny

        Terms & ConditionsAccessibility statement

        Loading footer...