Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

Expose Launch library "Name" in a Core data element so that it may be captured in an Analytics eVar

Avatar

Avatar
Shape 1
Level 2
Joe_Y_1
Level 2

Likes

10 likes

Total Posts

5 posts

Correct Reply

1 solution
Top badges earned
Shape 1
Boost 5
Boost 3
Boost 10
Boost 1
View profile

Avatar
Shape 1
Level 2
Joe_Y_1
Level 2

Likes

10 likes

Total Posts

5 posts

Correct Reply

1 solution
Top badges earned
Shape 1
Boost 5
Boost 3
Boost 10
Boost 1
View profile
Joe_Y_1
Level 2

10-12-2020

It would be helpful if there was a Core data element that returned the value of the Launch library "Name". This would make it easy to set the value to an Analytics eVar for debugging purposes. We name our libraries using the Major.Minor.Patch versioning convention and it would be helpful to know which Launch library a website visitor was using. Sometimes after a new library is published it seems like some visitors may have the old library cached in their browser. If we could capture the library "Name" as an eVar, we would know this for sure.

 

Joe_Y_1_0-1607646889929.png

 

3 Comments

Avatar

Avatar
Establish
MVP
evolytics_brian
MVP

Likes

70 likes

Total Posts

145 posts

Correct Reply

44 solutions
Top badges earned
Establish
Seeker
Give Back
Engage 1
Boost 50
View profile

Avatar
Establish
MVP
evolytics_brian
MVP

Likes

70 likes

Total Posts

145 posts

Correct Reply

44 solutions
Top badges earned
Establish
Seeker
Give Back
Engage 1
Boost 50
View profile
evolytics_brian
MVP

11-12-2020

@Joe_Y_1  - Love the idea! Until it can be implemented, have you considered building a custom JS data element to pull in values from _satellite.buildInfo and/or _satellite.property? You won't be able to get the library name, but _satellite.buildInfo.buildDate at least updates with each new build. And, since it's custom, you can include any other details you might want (environment, AppMesurement version, ECID version, etc).

Avatar

Avatar
Shape 1
Level 2
Joe_Y_1
Level 2

Likes

10 likes

Total Posts

5 posts

Correct Reply

1 solution
Top badges earned
Shape 1
Boost 5
Boost 3
Boost 10
Boost 1
View profile

Avatar
Shape 1
Level 2
Joe_Y_1
Level 2

Likes

10 likes

Total Posts

5 posts

Correct Reply

1 solution
Top badges earned
Shape 1
Boost 5
Boost 3
Boost 10
Boost 1
View profile
Joe_Y_1
Level 2

14-12-2020

@evolytics_brian - I've considered just using buildDate, but since we use the Major.Minor.Patch convention for our library name, capturing it would just make things simpler from a reporting perspective. We are currently capturing the Major.Minor.Patch AppMeasurement and ECID versions in an Analytics dimension, but they don't always change from library to library. Capturing an all-encompassing version number at the library level would just make things cleaner.

Avatar

Avatar
Contributor
Level 3
jkm-disco
Level 3

Likes

19 likes

Total Posts

109 posts

Correct Reply

13 solutions
Top badges earned
Contributor
Shape 1
Give Back
Affirm 10
Applaud 25
View profile

Avatar
Contributor
Level 3
jkm-disco
Level 3

Likes

19 likes

Total Posts

109 posts

Correct Reply

13 solutions
Top badges earned
Contributor
Shape 1
Give Back
Affirm 10
Applaud 25
View profile
jkm-disco
Level 3

28-12-2020

Hi @Joe_Y_1 ,

 

This sounds like a useful idea.

 

In the meantime, really like @evolytics_brian solution as a more automated method, but my team just uses a Core Constant variable to manually update and included with each library push. It's a bit tedious, but becomes ingrained in the workflow, and allows whatever naming convention seems appropriate. My team usually includes the name of the property itself, submission date, and the approver's initials, and we can determine, by looking at the publishing records, if the push was major/minor and the initials of the developer.